From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Type Categories for User-Defined Types |
Date: | 2008-07-29 22:06:08 |
Message-ID: | 88562268-F221-4C31-B435-868C03B88197@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jul 29, 2008, at 14:33, Tom Lane wrote:
> 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.
Actually, most seem to resolve to text okay. I'm adding aliases to
change behavior (e.g., case-insensitive matching in replace()). It's
the bazillion cast functions I'm having to add that are annoying (see
my previous post with the int8 example).
>> 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.)
No worries, it seems like a really good idea to me, regardless.
Thanks!
David
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Wanner | 2008-07-29 22:14:00 | Re: about postgres-r setup. |
Previous Message | Tom Lane | 2008-07-29 21:33:46 | Re: Type Categories for User-Defined Types |