| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, lr(at)pcorp(dot)us, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Domains versus polymorphic functions, redux |
| Date: | 2011-06-06 13:13:55 |
| Message-ID: | 1307366035.20678.10.camel@fsopti579.F-Secure.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On fre, 2011-06-03 at 13:53 -0500, Kevin Grittner wrote:
> Another long-range nicety would be something which I have seen in
> some other databases, and which is consistent with the inheritance
> theme, is that you can't compare or assign dissimilar domains -- an
> error is thrown. So if you try to join from the eye color column in
> a person table to the key of a hair color table, you get an error
> unless you explicitly cast one or both of them to the common type.
What you are looking for is the SQL feature called "distinct types".
The makers of the SQL standard have sort of deprecated domains in favor
of distinct types, because distinct types address your sort of use case
better, and prescribing the behavior of domains becomes weirder and
weirder as the type system becomes more complex. Which is pretty much
the same experience we've been having over the years.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-06-06 13:16:41 | Re: reducing the overhead of frequent table locks - now, with WIP patch |
| Previous Message | Peter Eisentraut | 2011-06-06 12:56:59 | Re: [PATCH] Bug in XPATH() if expression returns a scalar value |