Re: possible DOMAIN implementation

Hi,

Tom Lane wrote:
>
> John Reid <jgreid(at)uow(dot)edu(dot)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