Re: Problem with displaying "wide" tables in psql

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Problem with displaying "wide" tables in psql
Дата
Msg-id 21679.1398525361@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Problem with displaying "wide" tables in psql  (Greg Stark <stark@mit.edu>)
Ответы Re: Problem with displaying "wide" tables in psql  (Greg Stark <stark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: includedir_internal headers are not self-contained
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Decrease MAX_BACKENDS to 2^16