ср, 6 окт. 2021 г. в 19:13, Mark Rotteveel <m...@lawinegevaar.nl>:
>
> On 06-10-2021 17:32, Roman Simakov wrote:
> > 3. DROP TABLESPACE <TS NAME> [INCLUDING CONTENTS]
>
> 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.Original syntax and semantics have been taken from Oracle https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sqlrf/DROP-TABLESPACE.html It means that CASCADE handles objects dependent on objects in the dropping tablespace or such drop can be failed as well, in spite of INCLUDING CONTENT. I think it would be implemented as you described like DROP ... CASCADE but later. I see no problem with proposed syntax. > > 6. ALTER TABLE <TABLE NAME> DROP TABLESPACE > > > > Data of the table will be moved to the main database. > > Does this require a separate DROP TABLESPACE option? The same could be > achieved with ALTER TABLE <TABLE NAME> ALTER TABLESPACE ... > > where ... might be DEFAULT, MAIN or the explicit name of the main > tablespace (assuming it has a name). > > Using ALTER TABLESPACE also makes sense, because that is what's actually > happening. I have no objections but it would be useful to know other opinions. > > 9. ALTER INDEX <INDEX NAME> DROP TABLESPACE > > > > Data of the index will be moved to the main database. > > How will this work for indexes backing constraints? I see no problems with it. Could you explain what you mean? > > UTILITIES > > ======== > > > > Logical backup > > -------------------- > > gbak -b works as usual for now. It gets data from a database > > transparently working with tablespaces. > > > > Logical restore > > -------------------- > > gbak -c -TABLESPACE_MAP(PING_FILE) /path/to/file/map/tablespaces > > > > The option TABLESPACE_MAP(PING_FILE) specifies a path to the file > > which maps tablespace names on file names. For example, > > TS1 /path/to/tablespace1.dat > > TS2 /path/to/tablespace2.dat > > > > 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'd prefer if there is (also) an option to define the mapping on the > commandline without requiring users to first create the mapping file. Good point. I think it would be like gbak ... -ts TS1=/path/to/tablespace1.dat -ts TS2=/path/to/tablespace2.dat > I also think that using the old locations should be an explicit option, > so if a database backup has tablespaces, and no option is specified to > define the tablespace mapping, or the mapping is incomplete, restore > should fail *before it started to write anything*. or we can restore the whole backup in the single database file without tablespaces at all. I.e. merge every unmapped TS into the main database. > As an aside, we really need to look at how we handle commandline > options, because having really long commandline options with no simple > one or two character abbreviations is not very friendly IMHO. Maybe we > should consider switching to `-v` vs `--verbose-names` convention (with > backwards compatibility for existing options). > > > SOME DETAILS > > ============= > > > > pag_header in every tablespace is reserved and may be replaced by a > > new page type. > > I think it should be a separate page type. So am I. Currently tablespace headers are just not used. -- Roman Simakov Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
