вт, 12 окт. 2021 г. в 13:11, Vlad Khorsun <hv...@optima.com.ua>: > > 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: > > > 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 :)
OK) It won't be 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. Oracle's SYSTEM tablespace contains server-wide objects but not only database ones. But for now I agree we have two the most suitable options: SYSTEM, PRIMARY. > > 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. I think the option is good. We'll add in in the 3th version of the proposal. > > > 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 ? For tablespace yes. For indices the default tablespace is a tablespace of its table. (Definitely not related to "I hope you don't require to use TABLESPACE clause every time") > > 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). Exactly! > > 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. You suggest extending it in the PR or we can put it off? -- Roman Simakov Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
