11.10.2021 18:41, Vlad Khorsun wrote:
2. *ALTER TABLESPACE <TS NAME> FILE '/path/to/file'*
In DDL, ALTER usually combined with ADD | SET | DROP, so let follow this
convention. I.e. ALTER TABLESPACE <TS NAME> SET FILE '/path/to/file'
I'm not so sure about "usually", e.g. ALTER INDEX INACTIVE, ALTER DOMAIN
TYPE X, etc. As for me, SET is better for cases where DROP may also be
applied. But in fact we have both kinds of SET usage in the grammar and
I cannot say which is better.
Should we consider optional AT before TABLESPACE in all CREATE
<object> [AT] TABLESPACE <tsname> statements ?
I'd rather consider IN instead of AT, but also not insisting.
5. ALTER TABLE <TABLE NAME> *ALTER TABLESPACE {<TS NAME> | MAIN}*
Data of the table will be moved to the specified tablespace or the
main database.
This statement not alters tablespace itself, i.e. there should be SET
(and DEFAULT):
ALTER TABLE <TABLE NAME> SET TABLESPACE [TO] <TS NAME> | DEFAULT
+1
ALTER TABLE ALTER COLUMN ... SET TABLESPACE [TO] {<TS NAME> | DEFAULT}
Do you mean blobs or vertical partitioning here?
It's possible to create up to 253 tablespaces.
Two ID's is reserved for DEFAULT and TEMPORARY tablespaces, correct ?
I would reserve some more ID's for future system usage. I don't see it as
limitation for end users.
For regular tablespaces (created explicitly) - sure. But if we think
about automatically created partitions, even 253 tablespaces may become
a sad limit.
nbackup support is postponed.
At this stage I agree, but this must be 1st goal after initial
implementation, IMO.
The first PR may come without it, but I'm against releasing it until
nbackup is supported.
Page size is identical for every tablespace and the main database.
Support for many page sizes requires changes in page cache management
and should
be considered together. I don't see it as "must have" feature, btw.
Me neither.
Dmitry
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
