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.
In response to
pgsql-hackers by date
|Next:||From: Alvaro Herrera||Date: 2009-09-29 22:33:43|
|Subject: Re: Unicode UTF-8 table formatting for psql text output|
|Previous:||From: Tom Lane||Date: 2009-09-29 22:26:49|
|Subject: Re: pg_hba.conf: samehost and samenet [REVIEW] |