John Reid <[EMAIL PROTECTED]> writes:
>> Ugh. Don't overload pg_class with things that are not tables. I see no
>> reason that either pg_class or pg_attribute should be involved in the
>> definition of a domain. Make new system tables if you need to, but
>> don't confuse the semantics of critical tables.
> This is required due to the way inheritance is currently handled?
Not inheritance specifically. I'nm just looking at it on general design
principles: all the rows of a table should be the same kind of thing.
We shade that a little to allow views, sequences, etc, in pg_class, but
at least they're all things that have columns and so forth.
> From what I can remember inheritance works in postgresql at the class level.
> C.J. Date et al *strongly* argue that inheritance should be based on types,
> not relations/classes. This is still the case in 7.1?
Postgres doesn't really distinguish between tables and composite types
--- there's a one-for-one relationship between 'em. So we haven't had
to think hard about that point. If we did allow composite types without
associated tables, we probably would want tables to inherit from 'em
(which would mean some rethinking of the inheritance representation).
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
