Обсуждение: regression test client encoding

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

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.

> 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

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.

Peter Eisentraut <peter_e@gmx.net> 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