[fpc-devel] RFC: sqlDB extend TStatementType
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
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
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 = (
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