On 08/11/2021 12:11, Dmitry Yemanov wrote: > 08.11.2021 17:54, Dimitry Sibiryakov wrote: >> >>> Nope, I believe the new ID must be generated also by findRequest() if >>> the clone was found in the cache. >> >> Will it make impossible to detect repeatable execution of a prepared >> statement as opposite for execution of a new one every time? > > findRequest() is not used for user DSQL requests, only for > procedures/functions. So the top-level statement ID will be always > stable, as before. >
The solution does not work for the profiler then. Every request start must have its own ID, even DSQL ones. And preferable one ID link-able to MON$. Also, if DSQL requests have stable ID, it's weird that more than one called routines would be linked to it (even if not at the same time) through MON$CALL_STACK (where request IDs are more correctly used). > But if/when we separate compiled (cached) statements and running > statements, the ID will be reset before every execution and your > question may become actual. We'll either need a different "runtime" ID > or some backpointer (ID) from request to its statement. > In this case I think we better sooner introduce MON$COMPILED_STATEMENTS with some duplicate information already present in MON$STATEMENTS, declaring some columns of MON$STATEMENTS as deprecated to be removed in future versions. And make (now) MON$STATEMENTS ids represent request IDs generated on request start (for DSQL and routines). Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
