вт, 12 окт. 2021 г. в 11:56, Mark Rotteveel <m...@lawinegevaar.nl>:
>
> 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.
> """
Sorry, but I think I've answered that question and explained.
> > 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}]
Sure.
> > 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}]
Sure.
> > 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.
In other words due restore we require file names for the database and
for every tablespace. Sounds reasonable.
--
Roman Simakov
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
