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
> Good point --- so new members of STRING category aren't going to be
> 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
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)
LANGUAGE 'internal' IMMUTABLE STRICT;
CREATE OR REPLACE FUNCTION citext(inet)
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
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.
In response to
pgsql-hackers by date
|Next:||From: claudio lezcano||Date: 2008-07-31 17:52:45|
|Subject: compilig libpq with borland 5.5|
|Previous:||From: Tom Lane||Date: 2008-07-31 17:38:37|
|Subject: Fixing DISTINCT ON for duplicate keys|