On 9-9-2019 16:31, liviuslivius wrote:
Maybe this sample will be better.
Some sql tool which need run itself some internall queries but user need
different settings for he/she queries by this tool.
That doesn't make much sense either. The bind property settings are
intended to handle client compatibility issues. If your hypothetical
tool needs this in one situation, but not in another, then something is
wrong. I would expect a tool to either not support a new datatype (and
thus requiring the bind setting), or for it to support the new dataype,
thus removing the need to use anything other than native.
P.S. I also think about introducing some new SET command for sql plan
format retrived in MON$Statements i need to know if i should implement
some read command for this setting. I see that maybe it is not needed to
read. But i always like to know the current settings.
Ok, this makes a bit more sense then. Although why obtain it through
MON$STATEMENTS, when that is what the information API is for. And keep
in mind that querying MON$STATEMENTS is relatively expensive, so
building a feature that requires use of MON$STATEMENTS might not always
be a good idea.
Maybe instead of SET commands better will be to use writable context
variables? It is feature with already implemented read/write operations.
The current writable contexts are only for user data, extending that
with features to configure the session would require a separate context,
and that would be a bit odd because Firebird already has SET statements
for that purpose. That said, having something to obtain the current
value set could be helpful.
But maybe SET is something from some standard?
The SQL standard defines a number of session management statements that
all start with SET:
- SET SESSION CHARACTERISTICS AS <session characteristic list>
- SET SESSION AUTHORIZATION ..
- SET ROLE ..
- SET TIME ZONE ..
- SET CATALOG ..
- SET SCHEMA ..
- SET NAMES ..
- SET PATH ..
- SET DEFAULT TRANSFORM GROUP ..
- SET TRANSFORM GROUP FOR TYPE ..
- SET COLLATION ..
- SET NO COLLATION ..
So in that way, using SET for bind configuration, etc, seems a logical
extension.
For example PostgreSQL also has SET (see
https://www.postgresql.org/docs/11/sql-set.html), but it has the added
feature that you can use `SET LOCAL` to configure something for the
duration of the current transaction, and the effects of a `SET
[SESSION]` will be undone on rollback of the transaction used to execute
that `SET` statement.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
