пн, 11 окт. 2021 г. в 23:03, Vlad Khorsun <hv...@optima.com.ua>:
> 11.10.2021 21:23, Roman Simakov wrote:
> > пн, 11 окт. 2021 г. в 18:42, Vlad Khorsun <hv...@optima.com.ua <mailto:
> hv...@optima.com.ua>>:
> >
> > 11.10.2021 15:17, Roman Simakov wrote:
> > > SYNTAX
> > > =======
> > >
> > > Note: *MAIN* - is a name of the basic database file.
> >
> > Please, use *DEFAULT* for default (main) tablespace at "main"
> database file.
> > It is much more consistent with SQL and allows to avoid new
> unnecessary keyword.
> >
> >
> > I'd be happy to agree. Actually we took a look at Oracle syntax. The
> fact is that DEFAULT means different things. For example,
> > DEFAULT tablespace for indices is the tablespace of its table. That's
> why DEFAULT is not such an obvious name as we want it to be.
>
> This is matter of documentation, IMHO. BTW, why you don't like ORACLE's
> way ?
> It looks logical for me. If you want to avoid ambiguity we could introduce
> special syntax for the table's sub-objects (blob fields, indices,
> constraints),
> say use keyword TABLE or PARENT as tablespace name, for ex:
>
> CREATE INDEX … AT TABLESPACE {<TS NAME> | DEFAULT | TABLE}, or more
> natural
>
> CREATE INDEX … AT DEFAULT | TABLE TABLESPACE
> CREATE INDEX … AT TABLESPACE <TS NAME>
>
I had such an idea but didn't want to make up our own way.
If we go Oracle way and use DEFAULT we won't be able to move index data to
the main database for indices for a table at;) a tablespace. I.e. we can
move either to a named tablespace or to a default (table's) tablespace.
It seems Oracle uses the name SYSTEM for the main database. Do you like it?
Anyway the main database tablespace has to have a name. The question is
what name?
MAIN
PRIMARY
SYSTEM
DATABASE TABLESPACE
DATABASE
but definitely it could not be DEFAULT because DEFAULT meaning depends on
the context.
>
> in this case, when table's table space is changed, all dependent object
> should
> be changed accordingly
>
What do you mean saying "changed"? Now we explicitly set the tablespace
name for an index and when a table is moving leave the index where it was.
So subobjects are not bind to the parent. So does Oracle. Do you suggest
moving all dependent objects implicitly? So the question is to bind or not
to bind?
>
> // let me use AT until we agreed to use IN ;)
>
I'd like to get an answer from native speakers, but I think it's like a
database or file (in a database, in a file).
>
> > But MAIN exactly specifies the database itself. We especially have
> removed DEFAULT from the new version of the proposal because it's
> > better to explicitly require a tablespace name in the beginning. Later
> we can add defaults.
>
> I hope you don't require to use TABLESPACE clause every time ? If yes,
> you
> should define defaults anyway ;)
>
Definitely not. The point is that we cannot use DEFAULT as a name for the
main database. If so I decided not to introduce DEFAULT keyword at all. We
can add it when we understand how it works and what defaults are useful.
>
> > But if you have a good idea how to resolve this issue we will be happy
> to use it in the proposal.
>
> See above.
>
> > > 1. *CREATE TABLESPACE <TS NAME> FILE '/path/to/file'*
> > >
> > > 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'
> >
> >
> > Oracle syntax:
> >
> > ALTER TABLESPACE users
> > RENAME DATAFILE '/u02/oracle/rbdb1/user1.dbf',
> > '/u02/oracle/rbdb1/user2.dbf'
> > TO '/u02/oracle/rbdb1/users01.dbf',
> > '/u02/oracle/rbdb1/users02.dbf';
> >
> > I don't like it and we have only one data file actually and have no
> preferences here. We can make [SET] optional.
>
> ALTER somethings SET property TO value - looks as natural way to speak.
>
I don't mind but native speakers - say your words :)
>
> Yes, we may introduce RENAME and so on for every property of every
> altering
> object, but it looks too noisy for me.
>
> > > 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>*
> >
> > Should we consider optional AT before TABLESPACE in all CREATE
> <object> [AT] TABLESPACE
> > <tsname> statements ? And, perhaps, optional TO in ALTER <object>
> SET TABLESPACE [TO] <tsname>.
> > Below I'll use both AT and TO, but not insist on it.
> >
> >
> > Oracle doesn't use prepositions here.
>
> I already said that I'm not insist on it. BTW, in your case for (3)
> ORACLE uses RENAME ... TO :)
>
Yes. Unfortunately, Oracle syntax is far from ideal. I think we both agree
on that.
> > const USHORT DB_PAGE_SPACE = 1;
> >
> > // .. here all tablespace IDs. Keep TRANS_PAGE_SPACE rightafter
> DB_PAGE_SPACE
> >
> > const USHORT TRANS_PAGE_SPACE = 255; // is not used for tablespace id
>
> const USHORT TEMP_PAGE_SPACE = 256;
>
> This code was no relation with ODS. And it could be changed as required.
>
> > I would reserve some more ID's for future system usage. I don't see
> it as
> > limitation for end users.
> >
> >
> > I see no problem with it. At least for the first version we can use 63
> tablespaces for example (64 including the main database) .
> > We add another constant for the border of the available IDs.
>
> After DY's statement re. tablespace per partition, we should consider
> ability to create much more tablespaces.
>
I see no problem with increasing the limit. I see problems with reducing it
(someone may use them). So let's start from a small number 63. When we
implement partitions we increase it more consciously.
--
Roman Simakov
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
