Re: foreign_data test fails with non-C locale - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: foreign_data test fails with non-C locale
Date
Msg-id 1232396014.1406.7.camel@localhost
Whole thread Raw
In response to Re: foreign_data test fails with non-C locale  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: foreign_data test fails with non-C locale
List pgsql-hackers
Andrew Dunstan píše v pá 09. 01. 2009 v 12:16 -0500:
> 
> Guillaume Smet wrote:
> > On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >   
> >> However, the
> >> de facto policy is that we try to keep them passing in locales that
> >> are used by any of the regular developers.  I think it would be useful
> >> to have buildfarm members testing in a few common locales.
> >>     
> >
> > If you define common locales, I can set up as many new animals as
> > needed to cover the locales needed for any branch we'd like to test.
> >
> > Perhaps we should add a parameter to the buildfarm config file so that
> > the buildfarm script can check the locale is accepted and set it
> > directly. Considering that we won't have the locale information in the
> > animal description, it's a good way to have it in the report.
> >
> >
> >   
> 
> Sure, we can easily have buildfarm's initdb step set any locale (and 
> encoding, for that matter) we like. That's a simple change.

Will be possible to set more locales and run tests without recompilation
on all of them? For example I have installed all Solaris'es locales on
my animal, but currently it means that I need perform whole cycle for
each locale.
    Zdenek




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: libpq WSACleanup is not needed
Next
From: Zdenek Kotala
Date:
Subject: Re: foreign_data test fails with non-C locale