Robert Haas escribió: > On Tue, Sep 29, 2009 at 4:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Peter Eisentraut <pete...@gmx.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
