Re: [Firebird-devel] isc_info_sql_stmt_type/isc_info_sql_stmt_flags
On 19-08-2021 20:09, Dmitry Yemanov wrote: 19.08.2021 18:29, Dimitry Sibiryakov wrote: I'm not sure why the client application would need to know the statement type at all ;-) Distinguish DDL from DML and transaction control - quite useful if you accept SQL from outside of application. I mostly meant it's pointless to know the exact DML statement type. For an application, but for example the JDBC API wants to know update counts. Currently, Jaybird simply returns the highest value among insert, update and delete counts. However, knowing the exact type of statement one could also choose to return the 'best' value (i.e. insert count for INSERT, update count for UPDATE, delete count for DELETE, insert + update count for UPDATE OR INSERT, and insert + update + delete counts for MERGE). Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_info_sql_stmt_type/isc_info_sql_stmt_flags
On 19-08-2021 16:57, Adriano dos Santos Fernandes wrote: On 19/08/2021 11:43, Dmitry Yemanov wrote: Perhaps, although I'm not sure why the client application would need to know the statement type at all ;-) Before isc_info_sql_stmt_flags, I think that was the way to know if there is cursor or not. I think this was in response to my idea to introduce a new info item that reported the real statement type next to isc_info_sql_stmt_type which now more functions as 'how to handle the response'. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_info_sql_stmt_type/isc_info_sql_stmt_flags
19.08.2021 18:29, Dimitry Sibiryakov wrote: I'm not sure why the client application would need to know the statement type at all ;-) Distinguish DDL from DML and transaction control - quite useful if you accept SQL from outside of application. I mostly meant it's pointless to know the exact DML statement type. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_info_sql_stmt_type/isc_info_sql_stmt_flags
19.08.2021 16:43, Dmitry Yemanov wrote: I'm not sure why the client application would need to know the statement type at all ;-) Distinguish DDL from DML and transaction control - quite useful if you accept SQL from outside of application. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_info_sql_stmt_type/isc_info_sql_stmt_flags
19.08.2021 17:57, Adriano dos Santos Fernandes wrote: On 19/08/2021 11:43, Dmitry Yemanov wrote: Perhaps, although I'm not sure why the client application would need to know the statement type at all ;-) Before isc_info_sql_stmt_flags, I think that was the way to know if there is cursor or not. Correct. Therefore we should continue to support this "feature". I.e. any statement with resultset should return isc_info_sql_stmt_select. Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_info_sql_stmt_type/isc_info_sql_stmt_flags
On 2021-08-19 16:43, Dmitry Yemanov wrote: 19.08.2021 17:30, Mark Rotteveel wrote: 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. True, though I can think of some cases where it might be interesting to know the type of a statement, but there the concern would probably be more between select vs dml vs ddl vs start/end transaction vs etc, and not specifically insert vs update vs delete vs merge. This might be more relevant to me as a driver developer than for an application developer, and I can address most of that by doing a simple parse of (the prefix of) a statement (which I already need to do for some other functionality anyway). Mark Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_info_sql_stmt_type/isc_info_sql_stmt_flags
On 19/08/2021 11:43, Dmitry Yemanov wrote: > > Perhaps, although I'm not sure why the client application would need to > know the statement type at all ;-) Before isc_info_sql_stmt_flags, I think that was the way to know if there is cursor or not. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_info_sql_stmt_type/isc_info_sql_stmt_flags
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
Re: [Firebird-devel] isc_info_sql_stmt_type/isc_info_sql_stmt_flags
On 2021-08-19 15:17, Adriano dos Santos Fernandes 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. 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). As an aside, I wasn't aware of the existence of isc_info_sql_stmt_flags, and I haven't been able to find a mention in, for example, the release notes, nor in the doc directory. As such, this is an undocumented API, and you can't expect people to use it. Mark Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_info_sql_stmt_type/isc_info_sql_stmt_flags
On 8/19/21 4:17 PM, Adriano dos Santos Fernandes wrote: Hi! 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? That appears logical. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] isc_info_sql_stmt_type/isc_info_sql_stmt_flags
Hi! 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? Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
