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
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 |