[fpc-devel] RFC: sqlDB extend TStatementType

[LacaK]

Hi ,
now we have in sqlDB.pp:

TStatementType = (stNone, stSelect, stInsert, stUpdate, stDelete,
    stDDL, stGetSegment, stPutSegment, stExecProcedure,
    stStartTrans, stCommit, stRollback, stSelectForUpd);

Statement type is initialy determined by parsing SQL.Text in function 
TCustomSQLQuery.SQLParser and function TSQLConnection.StrToStatementType 
based on first word (token) of SQL.Text.
(i.e. 'SELECT ...' -> stSelect, 'INSERT ...' -> stInsert, 'CREATE ...' 
-> stDDL, etc.)
As you can see there is very limited count of sql statements which are 
recognized (but this is not problem ;-)).

Statement types stSelect and stExecProcedure have special meaning, 
because only these two types are allowed when using Open method
(i.e. only these two types are expecting, that return any data rows; see 
procedure TCustomSQLQuery.InternalOpen; )

Due to this fact also other sql statements like SHOW, PRAGMA, TRANSFORM, 
MySQL Admin.statements (CHECK TABLE, REPAIR TABLE etc.) which return 
data are mapped to stSelect (and others ATM unhandled like CTEs 'WITH 
...' and 'PIVOT ...' etc. must in future also map to stSelect).
This is OK as far as we do not expect, that stSelect = 'SELECT ...' , 
which is NON-intuitive assumption.

So I am thinking about adding new statement type stQuery and map all 
other than 'SELECT ...' statements that return dataset to this general 
statement type.
( See also http://docwiki.embarcadero.com/VCL/en/DB.TPSCommandType and 
http://docwiki.embarcadero.com/VCL/en/IBSQL.TIBSQLTypes )

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 ?
TIA
-Laco.