Обсуждение: 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