Re: Unicode UTF-8 table formatting for psql text output

Robert Haas escribió:
> On Tue, Sep 29, 2009 at 4:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> >> On Tue, 2009-09-29 at 12:01 -0400, Tom Lane wrote:
> >>> The bigger question is exactly how we expect this stuff to interact with
> >>> pg_regress' --no-locale switch.  We already do clear all these variables
> >>> when --no-locale is specified.  I am wondering just what --locale is
> >>> supposed to do, and whether selectively lobotomizing the LC stuff has
> >>> any real use at all.
> >
> >> We should do the LANG or LC_CTYPE thing only on the client,
> >> unconditionally.  The --no-locale/--locale options should primarily
> >> determine what the temporary server uses.
> >
> > Well, that seems fairly reasonable, but it's going to require some
> > refactoring of pg_regress.  The initialize_environment function
> > determines what happens in both the client and the temp server.
>
> This seems to mean that we can't apply this patch, since failing the
> regression tests is not an acceptable behavior. I think that means
> that the patch author needs to either do the necessary pg_regress
> refactoring or figure out some other solution that is acceptable to
> the community. Assuming that non-trivial pg_regress refactoring is
> required, I think we should mark this patch as Returned with Feedback,
> because that should really be a separate patch, and it's obviously far
> too late to submit new patches to this CommitFest.
>
> Objections?

Does the patch pass regression tests in normal conditions? If it does,
I see no reason to reject it. If it fails in --locale only, and even
then only when the given locale is UTF8, which IIRC it's a seldom-used
case, we can see about fixing that separately.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support