Re: "ERROR: operator is not unique" with Custom Data Type

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: "ERROR: operator is not unique" with Custom Data Type
Date: 2008-06-05 18:54:17
Message-ID: 3AC7B34C-30D6-4A43-9FDF-28D38D97AA6C@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jun 5, 2008, at 11:51, Tom Lane wrote:

>> I was thinking that the ::text should be cast to ::lctext, as that's
>> how `'a'::lctext = 'a'` works, but I keep going back and forth in my
>> mind. Maybe 'a'::lctext should not equal 'A'::text.
>
> It seems to me that lctext is sort of like a more-constrained version
> of text (like a domain),

Yes, exactly.

> which suggests that the lctext -> text
> direction can be implicit but the other direction should not be.

Ah, okay. That's a good way of putting it. So I should just eliminate
the implicit text -> lctext cast, then? That will solve the problem?

> Moreover, if you don't have lctext -> text be implicit then you
> will find that none of the non-comparison text functions work on
> lctext except with a cast; which is not the place you want to be.

No, quite right.

> I concur with Martijn that having both directions implicit is a
> Bad Idea.
>
> BTW, I would encourage you to think of this project as citext
> version 2,
> rather than inventing a new name for the datatype. All you'll
> accomplish with that is make it hard for users of citext to
> transition.

Fair enough. It was a working title, anyway.

Best,

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2008-06-05 19:15:14 Re: Overhauling GUCS
Previous Message Tom Lane 2008-06-05 18:51:29 Re: "ERROR: operator is not unique" with Custom Data Type