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
Re: [Firebird-devel] WireCrypt=Required and op_cond_accept
Never mind. It seems I figured it out. Looks like I can do op_cont_auth with public client data right there and then continue as usual. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] WireCrypt=Required and op_cond_accept
Hi *, I have a FB 3.0.7 with WireCrypt=Required. Sending op_connect with [Srp256, Srp], server responds op_cond_accept and selects Srp. So far so good. I continue with op_attach with isc_dpb_auth_plugin_name and isc_dpb_specific_auth_data for Srp. This results in "Client attempted to attach unencrypted but wire encryption is required". When the WireCrypt=Enabled I process the expected op_cont_auth, doing the dance and initializing the session key and finally doing op_crypt. But how I can do op_crypt earlier (because that's WireCrypt=Required seems to want) if I don't have session key yet (in op_connect)? -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
