08.11.2021 19:54, Adriano dos Santos Fernandes wrote:

In this case I think we better sooner introduce MON$COMPILED_STATEMENTS
with some duplicate information already present in MON$STATEMENTS,

Obviously, SQL text and plan belong to the statement. The rest looks request-specific (timestamp will represent request startup time).

However, MON$ATTACHMENT_ID is tricky. It's needed in MON$COMPILED_STATEMENTS now, but likely to be not needed once the shared statement cache is implemented. Also deprecate it then? Or maybe in the future some statements could not be globally cacheable and instead prepared per-attachment (as now)?

declaring some columns of MON$STATEMENTS as deprecated to be removed in
future versions.

We never removed columns from system tables and I'm not sure this is a good practice, as apps / components may have field names hardcoded / cached. Returning NULL for deprecated columns should be perfectly enough, IMO.

And make (now) MON$STATEMENTS ids represent request IDs generated on
request start (for DSQL and routines).

This may break existing apps (Dimitry Sibiryakov's question). But given that an alternative (via new MON$ table) will be available, perhaps this is not so critical.


Dmitry


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to