Re: Type Categories for User-Defined Types

Just realized that I forgot to add the DROP FUNCTION statements to the
uninstall script. New patch attached.

Best,

David



On Jul 31, 2008, at 10:42, David E. Wheeler wrote:

> On Jul 30, 2008, at 13:10, Tom Lane wrote:
>
>>> Yes, that was essentially my point. "arbitrary string of text" types
>>> are probably fairly rare, since one can just use text or citext or
>>> varchar.
>>
>> Good point --- so new members of STRING category aren't going to be
>> that
>> common, except for domains which apparently aren't bothering people
>> anyway.  I'll go ahead and make the change.  (I think it's just a
>> trivial change in find_coercion_pathway, and everything else should
>> Just Work.  If it turns out not to be trivial maybe we should
>> reconsider.)
>
> Wow. Really nice, Tom. Thanks!
>
> The attached patch has all the tests I added to my svn version
> against 8.3, and for which I had to write 60 additional cast
> functions. With your changes, I had to add only two more:
>
> CREATE OR REPLACE FUNCTION citext(boolean)
> RETURNS citext
> AS 'booltext'
> LANGUAGE 'internal' IMMUTABLE STRICT;
>
> CREATE OR REPLACE FUNCTION citext(inet)
> RETURNS citext
> AS 'SELECT text( $1 )::citext'
> LANGUAGE SQL IMMUTABLE STRICT;
>
> So the I/O casts are working beautifully. This is true even for
> ENUMs, which I couldn't get to magically cast with a function in
> 8.3. Thank you!
>
> If you don't want so many cast tests, I can remove all but a few of
> them. I wrote them for all the core user-visible types I could
> identify so that I could see how they behaved with text and then
> make citext work the same way. Such is not as important in HEAD,
> thanks to the I/O casting, so let me know if you want me to cut down
> on the number of tests (I was particularly uncertain about the xml
> type, since --with-libxml won't always be true, I expect).
>
> The other change in this patch is the addition of functions to make
> various string-comparison functions behave case-insensitively. I've
> started with all those that I was aware of from the previous
> documentation, and I've made them behave case-insensitively by
> writing SQL functions to hack it in. Ideally these would be done in
> C, but that started to get beyond my abilities. Suggestions welcome.
>
> The only other thing I wanted to look at doing with citext was to
> look for any other string-comparison functions I might have missed
> and do the same for them. Otherwise, I think we're golden.
>
> Many thanks,
>
> David
> <citext_casting.patch.gz>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers