Re: Type Categories for User-Defined Types

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