On 2019-02-28 20:57, Adriano dos Santos Fernandes wrote:
On 28/02/2019 16:54, Mark Rotteveel wrote:
The same can be asked for a lot of other information items that can be
obtained from isc_database_info. And the answer is invariably: because
it can be useful for an application or a driver itself to obtain that
information.
Why it could be necessary for a driver?
A feature request needs a requirement.
The requirement on Firebird is "the client (driver) wants to get the
actual user name in an efficient manner". What you seem to want is the
underlying rationale for that requirement (or the requirement on the
driver to have that requirement on Firebird).
One such requirement could be that the driver wants to fulfill something
like the JDBC api requirements of DatabaseMetaData.getUserName()
("Retrieves the user name as known to this database.",
https://docs.oracle.com/javase/8/docs/api/java/sql/DatabaseMetaData.html#getUserName--
). Jaybird currently uses the username it connected with, but in the
Firebird 3 situation of mapped users that is technically no longer
correct. In addition, if I ever implement trusted auth in Jaybird, or
some other form of authentication where the username is unknown to the
driver, then the incorrectness of the current implementation is even
greater.
And, yes, I can use CURRENT_USER, especially as I think this isn't a
method that will be used a lot, though I might be wrong. I can also
envision situations where others might have a need where performance is
of a greater importance. There the overhead of having to start a
transaction, create/prepare a statement, execute, fetch, close/drop
statement and end the transaction, might be too great compared to a
single isc_database_info request, especially if that might get executed
anyway as part of establishing the connection (which means near zero
overhead if you can add an extra info item to an existing
isc_database_info request).
Mark
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
