Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Lamar Owen writes:
> >> Ok, let me repeat -- the '--enable-locale' setting will not affect the
> >> collation sequence problem on RedHat. If you set PostgreSQL to use
> >> locale, it uses it. If you configure PostgreSQL to not us
Hi,
...
> LC_NUMERIC and LC_TIME
...
> The timeofday() make output via strftime() if you set LC_ALL, a query
> like: select timeofday()::timestamp;
Actually *I would* expect it to return a localized string. But then again I
always expect BE to use '.' as decimal point ( I must be damaged :-/ ).
On Fri, 24 Nov 2000, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> I propose, therefore, that in an --enable-locale installation, initdb
> >> should save its values for LC_COLLATE and LC_CTYPE in pg_control, and
> >> backend startup should restore these
[EMAIL PROTECTED] (Trond Eivind GlomsrØd) writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Also, since "LC_COLLATE=en_US" seems to misbehave rather spectacularly
> > on recent RedHat releases, I propose that initdb change "en_US" to "C"
> > if it finds that setting.
>
> It does not misbeh
Tom Lane <[EMAIL PROTECTED]> writes:
> Also, since "LC_COLLATE=en_US" seems to misbehave rather spectacularly
> on recent RedHat releases, I propose that initdb change "en_US" to "C"
> if it finds that setting.
It does not misbehave in glibc (it's not Red Hat specific).
Basically, glibc is the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Do local-enabled compiles have the LIKE optimization disabled always?
No. They do a run-time check to see what locale is active.
regards, tom lane
> I'm having a hard time believing Lamar's recollection, also. I wonder
> if there could have been some other factor involved? One possible line
> of thought: a non-locale-enabled compilation, installed to replace a
> locale-enabled one, would behave rather inconsistently if run on the
> same da
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Lamar Owen writes:
>> Ok, let me repeat -- the '--enable-locale' setting will not affect the
>> collation sequence problem on RedHat. If you set PostgreSQL to use
>> locale, it uses it. If you configure PostgreSQL to not use locale, the
>> collation
Lamar Owen writes:
> Ok, let me repeat -- the '--enable-locale' setting will not affect the
> collation sequence problem on RedHat. If you set PostgreSQL to use
> locale, it uses it. If you configure PostgreSQL to not use locale, the
> collation set by LANG, LC_ALL, or LC_COLLATE is _STILL_ hon
Peter Eisentraut wrote:
> Lamar Owen writes:
> > Yes, I want to ignore their default.
> If you want to do that then the infinitely better solution is to compile
> without locale support in the first place. (Make the locale-enabled
> server a separate package.) Alternatively, the locale of the
Tom Lane writes:
> > I certainly don't like treating en_US specially, when in fact all locales
> > are affected by this.
>
> Well, my thought was that another locale, say en_FR, would be far more
> likely to be something that the system's user had explicitly chosen to
> use at some point,
IIRC,
Lamar Owen writes:
> Yes, I want to ignore their default.
If you want to do that then the infinitely better solution is to compile
without locale support in the first place. (Make the locale-enabled
server a separate package.) Alternatively, the locale of the postgres
user to POSIX.
> I can d
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> I think your complaints about RedHat's default are right back in your
> lap ;-). Do you want to ignore their default, or not?
Yes, I want to ignore their default. This problem is more than just
cosmetic, thanks to the bugs that sparked
Lamar Owen <[EMAIL PROTECTED]> writes:
> A command-line argument to initdb would suffice to override -- maybe a
> '--initlocale' parameter??
Hardly need one, when setting LANG or LC_ALL will do just as well.
> Now, what sort of default for --initlocale.
I think your complaints about RedHat'
Tom Lane wrote:
> Don Baccus <[EMAIL PROTECTED]> writes:
> > Are you SURE you want to use en_US collation? [no]
> > (ask the question, default to no?)
> > Yes, a question in initdb is ugly, this whole thing is ugly.
> A question in initdb won't fly for RPM installations, since the RPMs
> try t
Don Baccus <[EMAIL PROTECTED]> writes:
> Are you SURE you want to use en_US collation? [no]
> (ask the question, default to no?)
> Yes, a question in initdb is ugly, this whole thing is ugly.
A question in initdb won't fly for RPM installations, since the RPMs
try to do initdb themselves (or am
At 07:32 PM 11/24/00 -0500, Tom Lane wrote:
>Possible compromise: let initdb accept en_US, but have it spit out a
>warning message:
>
>NOTICE: initializing database with en_US collation order.
>If you're not certain that's what you want, then it's probably not what
>you want. We recommend you set
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Collation was the same, regardless of the --enable-locale
> > setting. I got lots of 'bug' reports about the RPM's failing
> Hmm. I reviewed that thread and found this comment from you:
> : In a nutshell, yes. /etc/sysconfig/i18n
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Possible compromise: let initdb accept en_US, but have it spit out a
>> warning message:
> I certainly don't like treating en_US specially, when in fact all locales
> are affected by this.
Well, my thought was that another locale
Tom Lane writes:
> Possible compromise: let initdb accept en_US, but have it spit out a
> warning message:
>
> NOTICE: initializing database with en_US collation order.
> If you're not certain that's what you want, then it's probably not what
> you want. We recommend you set LC_COLLATE to "C" a
Lamar Owen <[EMAIL PROTECTED]> writes:
> Collation was the same, regardless of the --enable-locale
> setting. I got lots of 'bug' reports about the RPM's failing
> regression, giving an unexpected sort order (see the archives -- the
> best model thread's start post is:
> http://www.postgresql.org
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Oh, and to make matters that much worse, on a RedHat system it doesn't
> > matter if you build with or without --enable-locale -- locale support is
> > in the libc used, and locale support gets used regardless of what you
> > select on t
Possible compromise: let initdb accept en_US, but have it spit out a
warning message:
NOTICE: initializing database with en_US collation order.
If you're not certain that's what you want, then it's probably not what
you want. We recommend you set LC_COLLATE to "C" and re-initdb.
For more informa
Lamar Owen <[EMAIL PROTECTED]> writes:
> I am not at all happy about the 'broken' RedHat locale -- the quick and
> dirty solution is to remove or rename '/etc/sysconfig/i18n' -- but that
> doesn't cure the root issue.
Actually, that suggestion points out that just nailing down LC_COLLATE
at initd
Lamar Owen <[EMAIL PROTECTED]> writes:
> Oh, and to make matters that much worse, on a RedHat system it doesn't
> matter if you build with or without --enable-locale -- locale support is
> in the libc used, and locale support gets used regardless of what you
> select on the configure line :-(.
I
Tom Lane wrote:
> that contains only (or mostly) words like that. But I've got strong
> doubts that the average user of a default RedHat installation expects
> *all* data to get sorted that way, or that he wants us to honor a
> default that he didn't ask for to the extent of disabling LIKE
> opti
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> I have now received positive proof that en_US sort order on RedHat is
>> broken. For example, it asserts
>> '/root/' < '/root0'
>> but
>> '/root/t' > '/root0'
>> I defy you to find anyone in the US who will say that that is a
>> reasonable definitio
Tom Lane writes:
> >> Also, since "LC_COLLATE=en_US" seems to misbehave rather spectacularly
> >> on recent RedHat releases, I propose that initdb change "en_US" to "C"
> >> if it finds that setting. (Are there any platforms where there are
> >> non-bogus differences between the two?)
>
> > The
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I propose, therefore, that in an --enable-locale installation, initdb
>> should save its values for LC_COLLATE and LC_CTYPE in pg_control, and
>> backend startup should restore these settings from pg_control.
> Note that when thes
Tom Lane writes:
> I propose, therefore, that in an --enable-locale installation, initdb
> should save its values for LC_COLLATE and LC_CTYPE in pg_control, and
> backend startup should restore these settings from pg_control.
Note that when these are unset there might still be a "catch-all" loca
... and I am not going to allow 7.1 to go out without a fix for this
class of problems. I'm fed up ;-)
As near as I can tell from the setlocale() man page, the only locale
categories that are really hazardous for us are LC_COLLATE and LC_CTYPE;
the other categories like LC_MONETARY affect only I
31 matches
Mail list logo
