From: | Darren Duncan <darren(at)darrenduncan(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
Subject: | Re: Implementing DB2's "distinct" types |
Date: | 2013-04-22 09:01:24 |
Message-ID: | 5174FC64.5080204@darrenduncan.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2013.04.22 12:09 AM, Thomas Kellerer wrote:
>>> create type sno as varchar(50)
>>> with comparisons;
>>>
>>> create type pno as varchar(50)
>>> with comparisons;
>>>
>>> The following query will be rejected because sno and pno are not comparable
>>> (even though both are varchar columns):
>>>
>>> select *
>>> from p
>>> join s on s.sno = p.pno;
>>>
> I'm more interested if this can be dealt with on SQL level, rather than hacking
> Postgres itself
> (and it's not really a "request" for a new feature - I'm just curious)
To have proper semantics, what you want is for your new types sno and pno to
introduce new values into the type system, as CREATE TYPE does, rather than
being subtypes or aliases of the types they're defined over, as CREATE DOMAIN
does. I believe you can get what you want today with CREATE TYPE pno etc using
an attribute of varchar(50). Two types created in this way, their values should
never compare equal. So then, what you propose above would really just be
syntactic sugar for that. -- Darren Duncan
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Reiss | 2013-04-22 09:39:48 | PostgreSQL archiving last replayed WAL after recovery |
Previous Message | Thomas Kellerer | 2013-04-22 07:09:16 | Re: Implementing DB2's "distinct" types |