One workaround is to use DROP COLLATION IF EXISTS, that conveys the message without UTF8 in the message string.
But three other tests use ALTER COLLATION and I see no way but to comment / disable them. Currently have them disabled (with comments as to what they do, and why they're disabled). This updated patch doesn't have UTF8 string anywhere. Let me know if you prefer to remove the commented out tests completely. -- Robins Tharakan On 9 May 2013 07:44, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robins Tharakan <thara...@gmail.com> writes: > > Fabien pointed out that currently does not check for non-trivial > locales. I > > am still on the learning curve about LOCALEs and so, let me know if this > is > > a show-stopper. I guess I could look at it and get back in some time with > > more tests as Fabien points out. > > You really can't, because there is no guarantee that any given machine > will have anything except "C" and "POSIX". But there's another problem: > I believe this test will fail on any machine where the database is > created with an encoding different from UTF8, because that encoding is > named in some of the error messages in the expected output. > > This stuff is not easy to test in a portable way. > > regards, tom lane >
regress_collate_v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
