From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Implementing DB2's "distinct" types |
Date: | 2013-04-28 19:42:26 |
Message-ID: | CA+U5nMKNh1zO9Ns2MFSiSiKV69HzRM+r-w6snej2KMnHWzEjGw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 21 April 2013 12:17, Thomas Kellerer <spam_eater(at)gmx(dot)net> wrote:
> DB2 lets you define your own types (just as Postgres) but with the added
> benefit that you can mark them such that they are _not_ comparable, e.g. to
> avoid comparing "apples to oranges".
Sounds like an interesting feature we might want, but you should
discuss it on hackers.
What does the SQL standard say about this?
Is this actually useful for anything? I don't remember any complaints
about the current behaviour.
> As a type definition in Postgres can also include comparison functions, I
> have the feeling that this should be possible, but I don't have an idea on
> how to start to be honest.
Postgres supports both domains and row types. So you can treat this as
a row type with just one attribute.
Look at make_row_comparison_op() in src/backend/parser/parse_expr.c
If you can work out where to put it, you'd just need an if test to
prevent the row comparison recursing into its component types. That
would be stored on the pg_type catalog table as a boolean attribute,
defaulting to current behaviour.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | CR Lender | 2013-04-28 22:14:15 | Re: Checking for changes in other tables |
Previous Message | Martín Marqués | 2013-04-28 19:18:18 | Re: apt.postgresql.org broken dependency? |