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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
