Re: possible DOMAIN implementation - Mailing list pgsql-hackers

From John Reid
Subject Re: possible DOMAIN implementation
Date
Msg-id 3B04C11F.ED6124E4@uow.edu.au
Whole thread Raw
In response to possible DOMAIN implementation  (Horák Daniel <horak@sit.plzen-city.cz>)
List pgsql-hackers
Hi,

Haven't looked at this for a while, but I think some larger issues might raise
their (ugly?) heads here.

Domains are effectively types that inherit attributes of parent type, with
some additional information, so should be handled at the level of pg_type.
However might make sense to look at some other matters at the same time - I'm
thinking specifically of general inheritance and abstract data types.  AFAICT,
these are all closely related.  I started looking at this a while ago, but was
side-tracked by the winds of change ;-)

Tom Lane wrote:

> Horák Daniel <horak@sit.plzen-city.cz> writes:
> > When a new domain is created it will:
> > - put a record into pg_type with typnam = domain name, new code for
> > typtype = 'd' and typrelid = oid of a new record in pg_class (next line)

> - put a record into pg_class to create a fictional table with a new
> > relkind ('d'?), relnatts = 1, relname can be system generated
> > (pg_d_<domainname>)
>
> 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?

> > - put a records into pg_attribute and pg_attrdef with "column
> > (attribute) definition" - real type, size, default value etc., owner
> > will the fictional table from the previous step

ditto?

> > Then it will be required to modify functions that works with types. When
> > typtype of a retrieved type is 'd' then it will perform lookups into
> > pg_class, pg_attribute and pg_attrdef to find the real definition of the
> > domain. These additional lookups will also create a performace penalty
> > of using domains.
>
> Why shouldn't this info be directly available from the pg_type row?

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?   If the inheritance
mechanism could be changed to support types, the concept of inheritance for
classes should not be broken as these have entries in pg_type - possible some
code might be though :-(

Please note that I'm looking at forest scales (and also through the haze of
memory) - the trees might have an entirely viewpoint ;-)

cheers,
John
--
----------------------------------------------------------------------
john reid                                  e-mail john_reid@uow.edu.au
technical officer                                room G02, building 41
school of geosciences                           phone +61 02 4221 3963
university of wollongong                          fax +61 02 4221 4250

uproot your questions from their ground and the dangling roots will be
seen.  more questions!                                                      -mentat zensufi

apply standard disclaimers as desired...
----------------------------------------------------------------------




pgsql-hackers by date:

Previous
From: Forest Wilkinson
Date:
Subject: Re: Re: [SQL] possible row locking bug in 7.0.3 & 7.1
Next
From: "jacky_shu"
Date:
Subject: Need Postgresql ODBC Driver