19.08.2021 17:30, Mark Rotteveel wrote:
Since RETURNING was created, we change values of isc_info_sql_stmt_type
so clients can understand that statements with RETURNING have values.
With GH-6815, RETURNING will return cursors (except for INSERT INTO ...
VALUES RETURNING which works as before).
Should we avoid mangle isc_info_sql_stmt_type for cursor-based
RETURNING, as there is isc_info_sql_stmt_flags since v3 which is able to
put FLAG_HAS_CURSOR and make client know it must open a cursor, while
still know the statement type?
I think the biggest concern here is older tools or drivers that are not
aware of isc_info_sql_stmt_flags, but do use isc_info_sql_stmt_type to
inform how to handle/execute a statement, and would thus not be able to
handle this correctly. Given we already 'abuse' isc_info_sql_stmt_type
by returning isc_info_sql_stmt_exec_procedure for current RETURNING
statements, I think returning isc_info_sql_stmt_select for the new
situation is acceptable and probably even necessary.
I agree.
If we want/need some API to correctly identify the type of statement
even when RETURNING is present, we would need to add yet another info
item (e.g. isc_info_sql_stmt_type2 or isc_info_sql_real_stmt_type, or
something like that and then maybe deprecate isc_info_sql_stmt_type in
favour of the new statement type item and isc_info_sql_stmt_flags).
Perhaps, although I'm not sure why the client application would need to
know the statement type at all ;-) It still may be confusing, e.g. MERGE
actually performing as INSERT/UPDATE/DELETE.
Dmitry
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
