Greg Stark <st...@mit.edu> writes:
> I expect this regression test to fail on platforms that don't support
> utf-8 client-side (I'm assuming we such things?). I don't have such a
> platform here and I'm not sure how it would fail so I want to go ahead
> and apply it and grab the output to add the alternate output when it
> fails on the build-farm. Would that be ok?
Are you expecting to carry an alternate expected file for every possible
encoding choice? That does not seem workable to me, and even if we could
do it the cost/benefit ratio would be pretty grim. I think you should
drop the UTF8-dependent tests.
In other words: there are no encoding dependencies in the existing
standard regression tests. This feature is not the place to start adding
them, and two weeks past feature freeze is not the time to start adding
them either. We don't have time right now to shake out a whole new
set of platform dependencies in the regression tests.
If you feel these tests must be preserved someplace, you could add a
new regression test that isn't run by default, following in the
footsteps of collate.linux.utf8.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
