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>

in this case, when table's table space is changed, all dependent object should
be changed accordingly

// let me use AT until we agreed to use IN ;)

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 ;)

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.

  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 :)

...

     > SOME DETAILS
     > =============

...

     > It's possible to create up to 253 tablespaces.

        Two ID's is reserved for DEFAULT and TEMPORARY tablespaces, correct ?


Currently it's like

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.

Regards,
Vlad


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to