On 11-10-2021 14:17, Roman Simakov wrote:
[..]
SYNTAX
=======
[..]
3. *DROP TABLESPACE <TS NAME> [INCLUDING CONTENTS]*
If the tablespace contains some database objects the behaviour depends
on INCLUDING CONTENTS clause. if it is specified all database objects
in the tablespace will be dropped as well. Otherwise there will be an
error.
I want to repeat my objection against using [INCLUDING CONTENTS] instead
of {CASCADE | RESTRICT}:
"""
I think using {CASCADE | RESTRICT} instead of [INCLUDING CONTENTS] would
be better, as that fits with similar definitions in the SQL standard
(e.g. 11.2 <drop schema statement>, and Feature F032 "CASCADE drop
behaviour").
That is, you always have to specify either CASCADE (delete everything
contained in it), or RESTRICT (only delete if empty).
However, the SQL standard also specifies that all objects then need to
be dropped with CASCADE (so dependents are dropped as well), and
Firebird doesn't provide such feature (Feature F032 "CASCADE drop
behaviour") at the moment, and it is probably necessary for this to work
correctly, otherwise objects with dependents in other tablespaces will
result in the drop failing anyway.
Personally, I could live with not providing such feature for now, and
instead requiring the tablespace to be empty before dropping it.
"""
4. CREATE TABLE ...
(
...
FIELD TYPE CONSTRAINT ... USING INDEX ... *TABLESPACE {<TS NAME> |
MAIN}* -- field constraint tablespace
...
CONSTRAINT ... USING INDEX ... *TABLESPACE {<TS NAME> | MAIN}* -- table
constraint tablespace
...
)
*TABLESPACE <TS NAME>*
if the tablespace name is not specified *MAIN* will be used as default
tablespace for the table data.
A constraint will use the tablespace of the table if *TABLESPACE* is
omitted.
I assume you mean the entire clause is option, so: [TABLESPACE
{<ts_name> | MAIN}]
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.
6. CREATE INDEX … *TABLESPACE {<TS NAME> | MAIN}*
The index will be created in the specified tablespace or the main database.
If tablespace is omitted the index will be created in the tablespace of
the table.
I assume you mean the entire clause is option, so: [TABLESPACE
{<ts_name> | MAIN}]
7. ALTER INDEX <INDEX NAME>*ALTER TABLESPACE {<TS NAME> | MAIN}*
Data of the index will be moved to the specified tablespace or the main
database.
ODS CHANGES
=============
A new table RDB$TABLESPACES:
RDB$TABLESPACE_ID - SMALLINT
RDB$TABLESPACE_NAME - CHAR (63)
RDB$SECURITY_CLASS - CHAR (63)
RDB$DESCRIPTION - BLOB SUBTYPE TEXT SEGMENT SIZE 80
RDB$OWNER_NAME - CHAR (63)
RDB$FILE_NAME - VARCHAR (255)
A new field in RDB$INDICES:
RDB$TABLESPACE_NAME - CHAR (63)
A new field in RDB$RELATION_FIELDS:
RDB$TABLESPACE_NAME - CHAR (63)
New fields in RDB$RELATIONS:
RDB$TABLESPACE_NAME - CHAR (63)
RDB$POINTER_PAGE - INTEGER
RDB$ROOT_PAGE - INTEGER
Add page space id to page number in ods.h:index_root_page.
UTILITIES
========
[..]
Logical restore
--------------------
[..]
It allows you to restore tablespace contents to new places.
If the option is not specified gbak will use old locations for every
tablespace.
I still think this should be an explicit option as well, otherwise
surprising things - for the user - can happen when restoring a backup of
a database you didn't know had tablespaces.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
