Re: pl/perl and utf-8 in sql_ascii databases - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pl/perl and utf-8 in sql_ascii databases
Date
Msg-id 1342548452-sup-9344@alvh.no-ip.org
Whole thread Raw
In response to Re: pl/perl and utf-8 in sql_ascii databases  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
Excerpts from Kyotaro HORIGUCHI's message of mar jul 17 05:01:10 -0400 2012:

> > I think that's probably too much engineering for something that doesn't
> > really warrant it.  A real solution to this problem could be to create
> > yet another new test file containing just this function definition and
> > the query that calls it, and have one expected file for each encoding;
> > but that's too much work and too many files, I'm afraid.
>
> I agree completely. The balance between the additional complexity
> of regress and the what we would get from the complexity...

I had to remove both that test and the one about the 0x80, because it
wasn't working for me in either SQL_ASCII or Latin1, I forget which.
I'm not sure I understand the reason for the failure -- I was getting a
false result instead of true, which was unexpected.  Maybe there's a
trivial explanation for this .. or maybe it really is broken.

In any case, maybe it'd be a good idea to have more tests related to
encodings, if we can write them in some reasonable manner.  But only in
HEAD, I guess, because having to backpatch stuff and test every branch
in at least three encodings is just too annoying.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CompactCheckpointerRequestQueue versus pad bytes
Next
From: Peter Eisentraut
Date:
Subject: Re: [COMMITTERS] pgsql: Split contrib documentation into extensions and programs