Re: Problem with displaying "wide" tables in psql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Problem with displaying "wide" tables in psql
Date
Msg-id 21679.1398525361@sss.pgh.pa.us
Whole thread Raw
In response to Re: Problem with displaying "wide" tables in psql  (Greg Stark <stark@mit.edu>)
Responses Re: Problem with displaying "wide" tables in psql  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Greg Stark <stark@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: includedir_internal headers are not self-contained
Next
From: Tom Lane
Date:
Subject: Re: Decrease MAX_BACKENDS to 2^16