Using pg_regress --encoding sets both the server encoding of the test
database and the client encoding. (The choice of server encoding is
further constrained by locale, but that's a different issue.)

Looking at the expected variants of the pesky plpython_unicode test

plpython_unicode.out server encoding != SQL_ASCII and client encoding == UTF8; else ...
plpython_unicode_0.out server encoding != SQL_ASCII and client encoding != UTF8; else ...
plpython_unicode_3.out server encoding == SQL_ASCII

we can reproduce the first case using

make check LANG=C ENCODING=UTF8

and the third case using

make check LANG=C ENCODING=SQL_ASCII

But the only way to set up the second case is to create an installation
with a template database encoded in UTF8 and then run installcheck with
an encoding of, say, LATIN1, as the client encoding. Or something like
that, also depending on what else you have in your environment; it's
pretty weird.

It seems to me that the proper client encoding is actually determined by
the expected file, because that's what we are aiming to match. The
ability to override the client encoding when the test is run is actually
pointless.

What I'd suggest is that we take out the bit of code in pg_regress.c
that overrides the client encoding. Most of our test files are in
ASCII, so the client encoding shouldn't matter anyway. And where it
does matter, the test file itself should set it.

plpython_unicode.sql would then set the client encoding to UTF8, and the
second expected file would go away.

Would that make more sense?

diff --git i/src/test/regress/pg_regress.c w/src/test/regress/pg_regress.c
index b9ae622..f3d1ab2 100644
--- i/src/test/regress/pg_regress.c
+++ w/src/test/regress/pg_regress.c
@@ -727,12 +727,10 @@ initialize_environment(void)
putenv("LC_MESSAGES=C");

/*
- * Set encoding as requested
+ * Any necessary client encoding should be set by the test file.
+ * Otherwise we assume ASCII.
*/
- if (encoding)
- doputenv("PGCLIENTENCODING", encoding);
- else
- unsetenv("PGCLIENTENCODING");
+ unsetenv("PGCLIENTENCODING");

/*
* Set timezone and datestyle for datetime-related tests

Search Discussions

  • Tom Lane at Apr 15, 2011 at 8:09 pm

    Peter Eisentraut writes:
    What I'd suggest is that we take out the bit of code in pg_regress.c
    that overrides the client encoding.
    That doesn't seem like a particularly good idea in view of the recent
    changes in psql to try to intuit a default encoding from its locale
    environment. If I say --encoding in the command line, that means I want
    that encoding, not an environment-dependent one.
    Most of our test files are in
    ASCII, so the client encoding shouldn't matter anyway. And where it
    does matter, the test file itself should set it.
    plpython_unicode.sql would then set the client encoding to UTF8, and the
    second expected file would go away.
    Seems to me that plpython_unicode.sql could set the client encoding if
    it wants to, regardless of what pg_regress.c might think.

    regards, tom lane
  • Peter Eisentraut at Apr 15, 2011 at 8:47 pm

    On Fri, 2011-04-15 at 16:09 -0400, Tom Lane wrote:
    Peter Eisentraut <peter_e@gmx.net> writes:
    What I'd suggest is that we take out the bit of code in pg_regress.c
    that overrides the client encoding.
    That doesn't seem like a particularly good idea in view of the recent
    changes in psql to try to intuit a default encoding from its locale
    environment. If I say --encoding in the command line, that means I want
    that encoding, not an environment-dependent one.
    Actually, in light of that we might want to override PGCLIENTENCODING to
    SQL_ASCII, so we get back the results in ASCII (assuming an all-ASCII
    test), instead of whatever the client encoding might say, which might
    not be an ASCII superset.

    But I still don't see a use case for the user setting the client
    encoding when the test suite is run. This can only make things worse,
    not better.
    Seems to me that plpython_unicode.sql could set the client encoding if
    it wants to, regardless of what pg_regress.c might think.
    Yes, that would make sense in any case.
  • Tom Lane at Apr 15, 2011 at 9:14 pm

    Peter Eisentraut writes:
    On Fri, 2011-04-15 at 16:09 -0400, Tom Lane wrote:
    That doesn't seem like a particularly good idea in view of the recent
    changes in psql to try to intuit a default encoding from its locale
    environment. If I say --encoding in the command line, that means I want
    that encoding, not an environment-dependent one.
    Actually, in light of that we might want to override PGCLIENTENCODING to
    SQL_ASCII, so we get back the results in ASCII (assuming an all-ASCII
    test), instead of whatever the client encoding might say, which might
    not be an ASCII superset.
    Well, if you set client_encoding to that, what you will get is no
    conversion, which is exactly the same result as what you'll get from
    setting it the same as server_encoding, which is the current behavior.

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedApr 15, '11 at 7:57p
activeApr 15, '11 at 9:14p
posts4
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Peter Eisentraut: 2 posts Tom Lane: 2 posts

People

Translate

site design / logo © 2022 Grokbase