Feature #1113 - SQL Schemas #8445
Conversation
1ea94a4 to
b802478
Compare
b802478 to
0e6b394
Compare
|
Can someone please review this? |
|
|
||
| ```sql | ||
| ALTER SCHEMA <schema name> | ||
| <alter schema option>... |
There was a problem hiding this comment.
It is not clear if more than one option is allowed.
There was a problem hiding this comment.
I think ... makes it clear that it is.
There was a problem hiding this comment.
Maybe <alter schema option> [<alter schema option> ...] would make it more explicit
There was a problem hiding this comment.
Maybe
<alter schema option> [<alter schema option> ...]would make it more explicit
I don't see it this way, it just make things complicate to read. Anyone who (mis)understand the first version will do the same for this version.
We have others docs with the same convention (see README.case).
There was a problem hiding this comment.
Usually it is written like this:
ALTER SCHEMA <alter schema options>
<alter schema options> ::= <alter schema option> [<alter schema options>]
<alter schema option> ::= <option 1 | option 2 | etc>
| The monitoring tables now include schema-related information: | ||
|
|
||
| `MON$ATTACHMENTS` | ||
| - `MON$SEARCH_PATH`: search path of the attachment |
There was a problem hiding this comment.
SEARCH_PATH looks too generic, may be SCHEMA_SEARCH_PATH should be used ?
Or SCHEMA_PATH for short ?
Of course, if changed, it should be the same everywhere: context variable, DPB tag names, utilities command-line switches, etc
There was a problem hiding this comment.
The SQL standard has SET SEARCH_PATH command.
In docs, I tried to always call it schema search path.
In this case, I used same wording as the command.
|
On 4/3/25 14:24, Adriano dos Santos Fernandes wrote:
What is the better way to internally construct v2 DPBs then?
Looks like the common way (|ClumpletWriter
newDpb(ClumpletReader::dpbList, MAX_DPB_SIZE|) builds a limited v1.
No, it's not limited to v1. As long as clumplets fit into 255 bytes DPB
remains v1, as soon as one does not fit - converts it to v2 (i.e. next
in |ClumpletReader::dpbList).
IXpbBuilder works same way.
|
|
| For `CREATE`, `CREATE OR ALTER`, and `RECREATE` statements, the system searches only the **current schema** (the first | ||
| valid schema in the search path) for an existing object, and the new object is created in this same schema. | ||
| This rule also applies to `GRANT` and `REVOKE` statements for DDL operations without the `ON SCHEMA` subclause. If no | ||
| **current schema** is available (i.e., no valid schema exists in the search path), an error is raised. |
There was a problem hiding this comment.
What if SYSTEM is the first schema in the search path? AFAIU, it should be read-only for users. Will an error be raised or will be this schema ignored while resolving the name in DDL statements?
| This ensures backward compatibility with previous Firebird versions. | ||
|
|
||
| While the `SYSTEM` schema allows operations like index creation and manipulation of those indexes, it is otherwise | ||
| locked for DDL changes. Modifying objects within the `SYSTEM` schema through DDL operations is strongly discouraged. |
There was a problem hiding this comment.
It's related to my question above. I may understand a need to create/drop indices on system tables and it implies they're created in the system schema. But what other DDL are allowed (although discouraged) for the system schema?
There was a problem hiding this comment.
It's discouraged to even create indexes in system tables, I'd say.
I don't think there are others accepted DDL changes.
Is Modifying problematic here?
|
|
||
| ```sql | ||
| ALTER SCHEMA <schema name> | ||
| <alter schema option>... |
There was a problem hiding this comment.
Maybe <alter schema option> [<alter schema option> ...] would make it more explicit
src/dsql/DdlNodes.h
Outdated
|
|
||
| Firebird::string nameToString(const MetaName& name) | ||
| { | ||
| return name.toQuotedString(); |
There was a problem hiding this comment.
Are these methods really needed, provided that they're one-liners that could be used directly instead?
There was a problem hiding this comment.
No. It was necessary in a previous version where the toQuotedString methods had different names in the two classes.
| @@ -1 +1 @@ | |||
| 117 shift/reduce conflicts, 22 reduce/reduce conflicts. | |||
| 130 shift/reduce conflicts, 13 reduce/reduce conflicts. | |||
There was a problem hiding this comment.
Quite a lot of new shift/reduce conflicts, did you analyse whether the new syntax ambiguities safe?
Thanks to Alex.
No description provided.