[fpc-devel] RFC: sqlDB extend TStatementType

[LacaK]

>> This case is handled in PrepareStatement phase. In case of 
>> IBConnection is StatementType re-mapped to stExecProcedure and in 
>> case of PQConnection is re-maped to stSelect.
>
> That should obviously be changed to return the same type :-)
Yes any rules will be welcomed.

>
>>
>>>
>>>> But because this change is not unavoidable I am not sure if go this 
>>>> way or leave it as is and definitely abandon that stSelect is 
>>>> 'SELECT ...' ?
>>>> What do you think ?
>>>
>>> It is not clear to me what are you trying to accomplish with this 
>>> change ?
>> Hm, good point ;-)
>> Answer depends on answer of question what is purpose of StatementType ?
>> What kind of information do we expect ? How detailed ?
>>
>> In my mind is strange if stSelect is once true 'SELECT ' then 'INSERT 
>> INTO ... RETURNING ' then 'SHOW TABLES' then 'REPAIR TABLES' etc.
>> I would expect, that stSelect is always only 'SELECT' and other sql 
>> statements, that may return data map to any other StatementType ... 
>> may be, we can all other map to stExecProcedure (if we do not want 
>> introduce new statement type)? (like it is done internaly by fbclient 
>> for ...returning statements)
>
> As far as I know, the statementtype is mostly (if not only) used to 
> determine whether Open or ExecSQL must be used. For this purpose, no 
> new statement type is needed IMHO.
>
> If you want more detailed information, then the new statement type can be
> introduced.
Personaly I do not need it. I only think, that it will provide more 
clear design.

> But then one could argue that a lot of new types can be
> introduced: stAlterObject or stDDL and so on.
Exactly. It is not my intention make for each existing sql statement 
their corresponding StatementType (1:1)
My thinking is in oposite way. Have only small group of statements, 
theoreticaly something like:
stQuery ... selects, shows, pragmas, CTEs
stDML ... insert, update, delete, merge, replace
stExecProcedure ... executing procedures, functions, may be DML with ... 
returning ...
stDDL ... create, drop, truncate

and get rid of stGetSegment, stPutSegment, stSelectForUpd etc, which are 
IMO unnecessarily.
>
> One would also need to see to it that stQuery can be used both in Open 
> and
> ExecSQL, since you don't know in detail what the statement does.
meaning of stQuery would be, that statement return data, so it can also 
be used in ExecSQL, but result must be processed (silently discarded or so)
>
> Maybe Joost can comment on this.
If nobody will comment, I leave things as are. I only wanted bring to 
light this thing.

-Laco.