Re: foreign_data test fails with non-C locale
От | Zdenek Kotala |
---|---|
Тема | Re: foreign_data test fails with non-C locale |
Дата | |
Msg-id | 1232396014.1406.7.camel@localhost обсуждение исходный текст |
Ответ на | Re: foreign_data test fails with non-C locale (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: foreign_data test fails with non-C locale
|
Список | 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 по дате отправления: