11.10.2021 19:24, Dmitry Yemanov wrote:
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.
I said about regular usage, when some property of object is changed.
Of course there is some special cases with special syntax. Many of them
was introduced long time ago, btw ;)
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.
Question for native speaker ;)
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?
Blobs, as discussed earlier. I'm not consider partitioning, so far.
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.
I see no reason to create tablespace for every partition, but if we going to
support such scenario, we should use larger type for tablespace ID, of course.
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.
Sure.
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.
Good.
Regards,
Vlad
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
