ср, 6 окт. 2021 г. в 22:17, Dimitry Sibiryakov <s...@ibphoenix.com>:
>
> Roman Simakov wrote 06.10.2021 20:43:
> > Let me not describe every field. I hope most of them are obvious.
>
>    No, they aren't.

ok

A new table RDB$TABLESPACES # keeps metadata of tablespaces.

  RDB$TABLESPACE_ID - SMALLINT         # internally it will be
pagespaceid. probably can be avoided.
  RDB$TABLESPACE_NAME - CHAR (63)  # name of a tablespace
  RDB$SECURITY_CLASS - CHAR (63)     # security class for tablespace
  RDB$SYSTEM_FLAG - SMALLINT           # reserved
  RDB$DESCRIPTION - BLOB SUBTYPE TEXT SEGMENT SIZE 80 #description of
a tablespace
  RDB$OWNER_NAME - CHAR (63)           # owner of a tablespace
  RDB$FILE_NAME - VARCHAR (255)        # file where a tablespace data
are located
  RDB$OFFLINE - SMALLINT                      # reserved for future
implementation offline tablespaces
  RDB$READ_ONLY - SMALLINT                # reserved for future
implementation read only tablespaces

A new field in RDB$INDICES:
  RDB$TABLESPACE_NAME - CHAR (63)  # name of a tablespace

A new field in RDB$RELATION_FIELDS:
  RDB$TABLESPACE_NAME - CHAR (63)  # name of a tablespace

New fields in RDB$RELATIONS:
  RDB$TABLESPACE_NAME - CHAR (63)  # name of a tablespace
  RDB$POINTER_PAGE - INTEGER           # a number of the first pointer
page of a relation
  RDB$ROOT_PAGE - INTEGER                 # a number of the root page
of a relation

>    ID is not referenced anywhere and seems to have no purpose at all.

Probably it could be removed and pagespace IDs will be generated internally.

>    TABLESPACE_NAME being CHAR is pointless. CHAR was used in ancient times but
> new fields should prefer VARCHAR.

It's equal to other SQL_IDENTIFIERs

>    FILE_NAME limited to 255 characters is strange in modern world at least.

It refers to the existing fld_file_name. I don't mind increasing it
but think it's not a topic for tablespaces.

> > RDB$SYSTEM_FLAG is not currently used but I suppose it would be useful one 
> > day.
>
>    What for? There isn't going to be an automatically created tablespace for
> internal purposes, right? Where in host filesystem would it be created?..

I've not designed it and am not designing it now.

> > OFFLINE and READ_ONLY are a kind of physical properties and supposed
> > to be used but not in this merge request anycase.
>
>    Mostly I wanted to know the reason why they are SMALLINT instead of 
> BOOLEAN.

I think you are right and it must be BOOLEAN.

> > These fields are necessary for reliable implementation of moving data
> > pages to another tablespace. You'll be able to understand their
> > meaning in code.
>
>    Documentation also must contain the code?..

After documentation you will ask me why they are needed) For
documentation purposes I've provided a short description above.

--
Roman Simakov


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

Reply via email to