Re: Problem with displaying "wide" tables in psql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Emre Hasegeli <emre(at)hasegeli(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>, Sergey Muraviov <sergey(dot)k(dot)muraviov(at)gmail(dot)com>
Subject: Re: Problem with displaying "wide" tables in psql
Date: 2014-04-26 15:16:01
Message-ID: 21679.1398525361@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-26 15:20:56 Re: Decrease MAX_BACKENDS to 2^16
Previous Message Tom Lane 2014-04-26 15:05:46 Re: includedir_internal headers are not self-contained