Hi,
Tom Lane wrote:
>
> 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
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 s
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 critic
=?iso-8859-2?Q?Hor=E1k_Daniel?= <[EMAIL PROTECTED]> 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
Hello,
I have spend some thinking about implementation of DOMAIN capability.
Here are my ideas.
What is a domain? It is an alias for a type with size, constraints and
default values. It is like one column of a table. And this is the main
idea of my "implementation". It should be possible to impl
