Re: Type Categories for User-Defined Types - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Type Categories for User-Defined Types
Date
Msg-id 16848.1217367226@sss.pgh.pa.us
Whole thread Raw
In response to Re: Type Categories for User-Defined Types  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: Type Categories for User-Defined Types  ("David E. Wheeler" <david@kineticode.com>)
Re: Type Categories for User-Defined Types  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Type Categories for User-Defined Types  ("Ryan Bradetich" <rbradetich@gmail.com>)
List pgsql-hackers
"David E. Wheeler" <david@kineticode.com> writes:
> Well, there are already citext aliases for all of those operators, for  
> this very reason. There are citext aliases for a bunch of the  
> functions, too (ltrim(), substring(), etc.), so I wouldn't worry about  
> adding more. I've added more of them since I last sent a patch, mainly  
> for the regexp functions, replace(), strpos(), etc. I'd guess that I'm  
> about half-way there already, and there probably are a few I wouldn't  
> bother with (like timezone()).

That's exactly what I don't really want to do; if you are adding aliases
*only* to get rid of ambiguity-errors, and not to alter functionality,
then I think you're doing the wrong thing.  Adding more aliases can
easily make the situation worse.

> Anyway, would this issue then go away once the type stuff was added  
> and citext was specified as TYPE = 'S'?

Yeah, that's the point of the proposal.  I think the issue has come up
once or twice before, too, else I'd not be so interested in a general
solution.  (digs in archives ... there was some discussion of this
in connection with unsigned integer types, and I seem to recall older
threads but can't find any right now.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Type Categories for User-Defined Types
Next
From: "David E. Wheeler"
Date:
Subject: Re: Type Categories for User-Defined Types