FirebirdSQL
FB 6.x. Provide ability to disable output of schema name (via config, ISQL and API)
Following is example of error message in OLTP-EMUL test:
Statement failed, SQLSTATE = HY000
exception 18
-"PUBLIC"."EX_CAN_NOT_SELECT_RANDOM_ID"
-2025-08-01T15:18:41.0360 ATT_839 TRA_4111 no id >= <?> found in 'v_add_invoice_to_stock ' within scope <?> ... <?>
-At procedure "PUBLIC"."SP_GET_RANDOM_ID" line: 338, col: 1
At procedure "PUBLIC"."SP_ADD_INVOICE_TO_STOCK" line: 156, col: 1
-At procedure "PUBLIC"."SP_GET_RANDOM_ID" line: 357, col: 1
At procedure "PUBLIC"."SP_ADD_INVOICE_TO_STOCK" line: 156, col: 1
-At procedure "PUBLIC"."SP_ADD_INVOICE_TO_STOCK" line: 312, col: 1
-At block line: 27, col: 17
-At block line: 57, col: 12
After line 184 in file e:\temp\logs.oltp60\sql\tmp_random_run.sql
I really can't imagine what's the point to display schema name if all objects are from PUBLIC or SYSTEM schemas. Same about execution plans (in legacy and explained form).
I really can't imagine what's the point to display schema name if all objects are from PUBLIC or SYSTEM schemas.
Exactly because there is at least two schemas in a database, it is very important for diagnostic purposes to provide exactly qualified object names in messages.
Personally the only thing I would get rid of in the example above is unnecessary delimiters.
- PUBLIC is not a special schema, despite the fact that it is created automatically when the DB is created. It can be deleted altogether.
- For consistency. If you don't have other schemas, you won't understand this. Imagine that you created
EX_CAN_NOT_SELECT_RANDOM_IDin another schema and this exception came from there. PUBLICmay not always be the current schema. The search path may be changed.
In fact, the full name in error texts and plans is a blessing, because it does not depend on any current settings. Think about application developers, how much easier it is for them to see the full name of an object. The fact that many tests need to be redone is temporary and minor difficulties.
Personally the only thing I would get rid of in the example above is unnecessary delimiters.
That only means more conditional logic to determine if it should be a quoted identifier or not. At least now it is consistent, and it should remain this way, IMHO.
I think this should be closed as won't fix. Doing this is inconsistent, adds unnecessary complexity, and could potentially hide real problems.
it is very important for diagnostic purposes to provide exactly qualified object names in messages.
If DB developer will not create some 'my_schema' then:
- SYSTEM may occur only for RDB/SEC tables.
- PUBLIC - for all user objects.
How can anyone get confused in this ?
could potentially hide real problems.
The real problem (currently) is extremely cumbersome output of errors and plans
Pavel, a developer does not create schemas just because they are not available to him. As soon as they become available to him and the data access components support them, he will start creating them. For example, I already know which metadata objects I would like to move to a separate schema. Let's not make our lives more difficult in the future by making them easier now.
I don't see any problems with outputting errors. Believe me, application developers will only say thank you for the full names.
As for plans, with the advent of RDB$SQL.EXPLAIN it became possible to very easily output a plan in the desired format if you don't like the current output.
So, the ability to only temporary switch off these schemas from output in 6.x - taboo ?
Just string replace the undesired part from the message yourself if you don't want to present it to the end user. Formatting should not be the part of the SQL engine, but the application. Hiding information could lead to PITA situations.
That only means more conditional logic to determine if it should be a quoted identifier or not.
May be I misunderstand you, but initially quoted identifiers will be still shown as quoted in the messages. It you mean Firebird internals that make up these messages, then yes, some more conditions will be unavoidable. Fortunately these conditions are already in place for ISQL EXTRACT, for example.
Hiding information could lead to PITA situations.
Why ?? if all user objects belong to PUBLIC schema, and this is done intentionaly (during development of some project in 6.x) - what 'important info' could be hidden from me in such case ?
Just string replace the undesired part from the message yourself if you don't want to present it to the end user.
How can this be done using ISQL ? Yes, of course it can be implemented if we use pipe and handle with this output by another tool, but why should we make our life complicated ?
Stop treating the PUBLIC scheme as something special. Consider it to be exactly the same scheme as all the others. As soon as you start treating all schemes as equal, the desire for some special formatting will fall away.
what 'important info' could be hidden from me in such case ?
You think as a database developer who has a full control over the database. It is not necessary the case and a third-party support will be very puzzled if an end-user created an object in different schema which is causing an error that is impossible in the original database.
"if all user objects belong to PUBLIC schema". This is YOUR APPLICATIONS property, which Firebird has no infomation. Maybe you need/want a database property indise RDB$DATABASE that it is "schemaless"?
It is not necessary the case and a third-party support will be very puzzled if an end-user created an object in different schema
I speak NOT about disabling them. By default they should be enabled (as now). I want just to have ability to turn off their names and unnecessary quotes in output (temporary!) -- and that's all.
PS. Can't understand at all: how could we even live for 25 years w/o schemas... :-/
There is no RDB$DATABASE without a schema. I will even say more, RDB$DATABASE is exactly the same system table from the SYSTEM schema, like all the others. Its widespread use in the user is due ONLY to historical reasons. Adriano has already made concessions by making the SYSTEM schema always included in SEARCH PATH.
Maybe you need/want a database property indise RDB$DATABASE that it is "schemaless"?
Couldn't get this Q. Please clarify.
It is not necessary the case and a third-party support will be very puzzled if an end-user created an object in different schema
I speak NOT about disabling them. By default they should be enabled (as now). I want just to have ability to turn off their names and unnecessary quotes in output (temporary!) -- and that's all.
PS. Can't understand at all: how could we even live for 25 years w/o schemas... :-/
No, the point is that we shouldn't introduce needless complexity and goldplating (i.e. unnecessary control knobs and configuration), just to pretend schemas don't exist, especially not if - as I read it - it only is to prevent rework for tests that verify hardcoded messages. Schemas are the new reality of Firebird 6 and later, and we'll need to live with such consequences.
If that means more work in the tests, e.g. to make the checks templated or otherwise conditional on the target version, then that is an investment that needs to be made.
it only is to prevent rework for tests that verify hardcoded messages
This test not assumes any logic that is based on search of hardcoded messages (perhaps only some known values of SQLSTATE are checked, and no more). I just want to note that such messages (and plans) are simply difficult to read. // poor eyes of those who will be forced to analyze something really serious
Yes, the output is insane and not readable (with double quotes). Does this mean that in addition to "PUBLIC". there can be "public" ???
Yes, the output is insane and not readable (with double quotes). Does this mean that in addition to "PUBLIC". there can be "public" ???
Of course:
C:\FBTESTING\OLTP-EMUL.TMP\src>isql /:employee
Database: /:employee, User: SYSDBA
SQL> create schema "public";
SQL> create schema "system";
SQL> show schema;
PUBLIC
"public"
"system"
That only means more conditional logic to determine if it should be a quoted identifier or not. Fortunately these conditions are already in place for ISQL
EXTRACT, for example.
Nope. Historically only not uppercase identifiers are surrounded by double quotes. Completely uppercase identifiers are NOT doublequoted, for no purpose.
Yes, the output is insane and not readable (with double quotes). Does this mean that in addition to "PUBLIC". there can be "public" ???
SQL> create schema "public"; SQL> create schema "system"; SQL> show schema; PUBLIC "public" "system"
for god's sake - no, please!
PUBLIC "public" "system"
Wait, where is original SYSTEM?
Completely uppercase identifiers are NOT doublequoted, for no purpose.
Yes, and this is what I wrote in the beginning of this thread: I would prefer to see them not quoted in the error messages.
I would prefer to see them not quoted in the error messages.
if this will be done - i hope you will participate in updating of 400+ tests together with me ? ;-)
Yes, the output is insane and not readable (with double quotes). Does this mean that in addition to "PUBLIC". there can be "public" ???
Of course that is possible, just like with any other identifier. It would be stupid to create such names, but of course it would be possible to do so. Just like you can now create tables called "CUSTOMER", "Customer" and "customer".
it only is to prevent rework for tests that verify hardcoded messages
This test not assumes any logic that is based on search of hardcoded messages (perhaps only some known values of SQLSTATE are checked, and no more). I just want to note that such messages (and plans) are simply difficult to read. // poor eyes of those who will be forced to analyze something really serious
I find the consistency good, and very readable. I think this is something you will get used to.
I would sooner complain about the inconsistency in the message formatting where some lines are prefixed with - and others (with similar text) are not for seemingly no reason..
Just like you can now create tables called
"CUSTOMER","Customer"and"customer".
But you can create CUSTOMER, Customer and customer, and get just CUSTOMER, without double quotes in any case (nor input, neither output). And, in your first "CUSTOMER" doublequotes are useless, and harm reading. (so, you understand that I'm against doublequoted identifires). But, what if I will GRANT SOMETHING to "Public" ... ? Why these words as PUBLIC and SYSTEM are allowed in schemas to be doubleqouted, and moreower, to be created in lower case, becoming different identifiers? What is the purpose of this strange feature?