Re: "ERROR: operator is not unique" with Custom Data Type - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: "ERROR: operator is not unique" with Custom Data Type
Date
Msg-id 3AC7B34C-30D6-4A43-9FDF-28D38D97AA6C@kineticode.com
Whole thread Raw
In response to Re: "ERROR: operator is not unique" with Custom Data Type  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "ERROR: operator is not unique" with Custom Data Type
Next
From: Greg Smith
Date:
Subject: Re: Overhauling GUCS