Re: Backpatching of "Teach the regular expression functions to do case-insensitive matching" - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Backpatching of "Teach the regular expression functions to do case-insensitive matching"
Date
Msg-id 1640.1305065143@sss.pgh.pa.us
Whole thread Raw
In response to Re: Backpatching of "Teach the regular expression functions to do case-insensitive matching"  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Backpatching of "Teach the regular expression functions to do case-insensitive matching"  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> I'm all for more test suites, but we should make them as widely
> accessible and accessed as possible so that they get maintained.

Yeah.  My preference would really be to push something like
collate.linux.utf8 into the standard regression tests, but we'd
first have to get it to where there was only one .sql file and
not more than three or so variant expected files (one of which
would be the one for platforms that don't support locale_t,
analogous to the no-support expected file for the xml test).

If we were at that point, then instead of having a separate make target,
I'd be very strongly tempted to include the test in the standard tests
by the expedient of having it create and \c to a separate database with
suitable values of ENCODING, LC_COLLATE, etc.

The lack of initdb support for getting more-or-less-standard collation
entries into pg_collation on Windows seems to be the major missing piece
from here (dunno if Peter is aware of others).  If we don't fix that
before release, we're going to regret it anyway IMO, because of the
inevitable tide of questions/complaints from Windows users trying to use
the collation feature.  We've already seen at least one such from a beta
tester.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Infinity bsearch crash on Windows
Next
From: Eric McKeeth
Date:
Subject: Re: VARIANT / ANYTYPE datatype