Re: possible DOMAIN implementation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: possible DOMAIN implementation
Date
Msg-id 12167.990122325@sss.pgh.pa.us
Whole thread Raw
In response to possible DOMAIN implementation  (Horák Daniel <horak@sit.plzen-city.cz>)
List pgsql-hackers
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.

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

> 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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: Upgrade issue (again).
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql/ oc/src/sgml/runtime.sgml rc/backend/uti ...