Re: possible DOMAIN implementation - Mailing list pgsql-hackers

Hi,

Tom Lane wrote:
> 
> John Reid <jgreid@uow.edu.au> 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.

These could actually be defined in pg_type (or an inherited class
pg_class_def)?

> 
> > 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).

Yes.  I had a superficial look at SQL99 abstract data types a while
back, but didn't get very far.  I didn't raise any of the issues I came
across at the time as everyone was busy with the 7.1 release.  My
interest is primarily in GIS data storage, which is a bit more involved
than most applications.  Ability to define complex types without having
to instantiate them (or else implement them as user defined type when
they are really a class) would be especially handy for GIS schemas.  Not
quite sure what else yet ;-) 

IMHO, it is probably worth looking at this further - it seems to me that
these issues will have a significant impact when dealing with
implementation of the SQL99 standard, so probably easier to deal with
them now/soon?

FWIW, some *really sketchy* ideas from when I looked at this:
1) pg_inherits should point at pg_type
2) some (most?) of the functionality of pg_class should be moved into
pg_type ((2a) maybe using inherited class pg_class_def?)
3) pg_class should purely contain relation specific stuff only (type,
indexes, owner)

another alternative would be introduce a new system table pg_relation
for relations, making pg_class the equivalent of pg_type but used for
handling complex types.  Then again, this is effectively the same as
(2a)? Might make sense to think about renaming the tables anyway, as to
me pg_class seems to imply the class definition, rather than the
instantiation. Then we would have

pg_type
pg_class inherits pg_type
pg_relation

I could forsee some real chicken or the egg problems in system
initialization.  How are these handled currently?
cheers,
John