Feature #1113 - SQL Schemas #8445
Conversation
asfernandes
force-pushed
the
work/schema
branch
from
1ea94a4 to
b802478
Compare
asfernandes
force-pushed
the
work/schema
branch
from
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.
| 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.
| -- SCHEMA2 | ||
| -- schema3 | ||
| -- "schema 4" | ||
| -- "schema "5" |
There was a problem hiding this comment.
-- "schema "5"" ? Looks like last double quote is missed
There was a problem hiding this comment.
No, it closes the double-quote started at "schema .
|
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.
|
|
No description provided.