[fpc-devel] RFC: sqlDB extend TStatementType

[michael.vancanneyt at wisa.be]

On Thu, 19 Apr 2012, LacaK wrote:

>
>> 
>> In fact, this is not quite correct.
>> 
>> Insert into table (a,b,c) returning values (x,y,z)
>> 
>> can also be done with an Open, yet it will probably get stInsert as type.
> 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 :-)

>
>> 
>>> 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. But then one could argue that a lot of new types can be
introduced: stAlterObject or stDDL and so on.

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.

Maybe Joost can comment on this.

Michael.