From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Rod Taylor" <rbt(at)zort(dot)ca> |
Cc: | "Thomas Lockhart" <thomas(at)fourpalms(dot)org>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Domains and type coercion |
Date: | 2002-03-21 22:45:48 |
Message-ID: | 7200.1016750748@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Rod Taylor" <rbt(at)zort(dot)ca> writes:
> It would be fairly straight forward to simply copy the domain base
> type into the atttypid, then create an atttypdomain (normally 0,
> except in the case of a domain). Everything would use the attypid,
> except for \d and pg_dump which could use the domain if it exists.
> Is this something I should do?
No, because it's quite irrelevant to the problem of type coercion,
which works with expressions; attributes are only one part of the
expression world.
Actually, considering Fernando's point that a CAST ought to apply the
constraints associated with a domain type, your attribute-based
implementation is wrong anyway. Rather than merging the domain
constraints into the table definition (which will be a nightmare for
pg_dump to sort out, anyway) keep 'em separate. The constraints could
be checked during casting from a base type to a domain type --- take a
look at the existing mechanism for enforcing typmod (length limits),
which after all is a simplistic kind of domain constraint.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tony Reina | 2002-03-22 00:15:27 | Problem compiling PostgreSQL 7.2 on IRIX 6.5.15f |
Previous Message | Dmitry Tkach | 2002-03-21 21:33:31 | A bug in gistPageAddItem()/gist_tuple_replacekey() ??? |