Re: Joining data tables and system tables
Date: 4 Jan 2003 10:32:05 -0800
Message-ID: <bdf69bdf.0301041032.4164ad44_at_posting.google.com>
pbrazier_at_cosmos-uk.co.uk (Paul) wrote in message news:<51d64140.0301020238.2d59bc3e_at_posting.google.com>...
> I think that the system tables shouldn't contain
> themselves though for this exact reason (which they seem to do at
> least in SQL Server). Maybe we need a "system catalogue catalogue" to
> detail these (etc., etc.)?
>
> If I had something to link metadata to data I could get a paradox if I
> define a relation as: "one column with the names of all relations in
> the database that don't contain their own names as strings of data in
> one of their tuples" (should that relation just defined list itself or
> not?).
Catalog table TABLES contain relations as tuples. There is no self-referential problem here. On the other hand, an imaginary system table ROWS that contains all the rows in the database (or CELLS as suggested in the other post), would definetely be a problem. Obviously ROWS table couldn't include all the rows that belong to ROWS, so the definition should be corrected to:
Table ROWS enumerates all the rows in the database, except itself
Next, there is really no logical difference between a materialized relation -- table -- and a virtual one -- view. Why should we enumerate rows from tables only? IMHO, this problem is more serious than the self-reference, and a reason why neither CELLS nor ROWS catalog table exist. Received on Sat Jan 04 2003 - 19:32:05 CET