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't confuse the
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 critical
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
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
=?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 table
