[fpc-devel] RFC: sqlDB extend TStatementType

LacaK lacak at zoznam.sk
Thu Apr 19 10:15:04 CEST 2012

> 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.

>> 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 
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)

There is no technical problem only in my mind current situation is bit 
strange (may be I can say "uncomplete" or "unintuitive" or "unclear").
But if nobody else see it as I do, then I can live with this ;-)

Looking at sources it seems, that property StatementType is protected so 
it is used mostly for internal purposes.

Note, that there is in db.pas also:
  TPSCommandType = (
    ctQuery,                     <---
    ctSelect,                     <---
and virtual method of TDataSet.PSGetCommandType
So in future in TCustomSQLQuery somebody may want override 
PSGetCommandType and do maping from StatementType to CommandType
(this is other reason why I am thinking about new stQuery)


More information about the fpc-devel mailing list