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
...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 = (
ctUnknown,
ctQuery, <---
ctTable,
ctStoredProc,
ctSelect, <---
ctInsert,
ctUpdate,
ctDelete,
ctDDL
);
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)
L.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
