12.10.2021 9:09, Roman Simakov wrote:
пн, 11 окт. 2021 г. в 23:03, Vlad Khorsun <hv...@optima.com.ua
<mailto: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> <mailto: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.
Now I understand you better, thanks. But I still against word MAIN :)
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.
'SYSTEM' is good choice. All system relations is here. So, engine will always
create
tablespace with name 'SYSTEM', and put all system relations and TIP here,
correct ?
'SYSTEM' tablespace can't be renamed and could (should?) be marked as system
one.
The question is what name?
MAIN
PRIMARY
SYSTEM
DATABASE TABLESPACE
DATABASE
SYSTEM (best) or PRIMARY, imho.
but definitely it could not be DEFAULT because DEFAULT meaning depends on the
context.
Ok.
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?
Yes. I assumed sub-objects placed in the same tablespace as object itself
should be
moved all together (i.e. bound). But now I think there should be option to
[not]move
sub-objects when object moved into new tablespace.
// 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).
No problem :)
> 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.
Hmm... when object is creating and tablespace was not specified, we must use
something
(by default). Obvious choice is to use 'SYSTEM' tablespace, correct ?
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.
Ok. So, we should remove all mentions of MAIN in your next version of
proposal, correct ?
If one need to place\move object into main database file (tablespace) name
'SYSTEM' should
be used explicitly (so far).
...
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.
I speak about data type used in ODS for tablespace ID. It seems INT should be
used,
not SMALLINT.
Regards,
Vlad
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
