From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Backpatching of "Teach the regular expression functions to do case-insensitive matching" |
Date: | 2011-05-10 22:05:43 |
Message-ID: | 1640.1305065143@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Eric McKeeth | 2011-05-10 22:21:36 | Re: VARIANT / ANYTYPE datatype |
Previous Message | Greg Smith | 2011-05-10 22:02:26 | Infinity bsearch crash on Windows |