Re: A creepy story about dates. How to prevent it? - Mailing list pgsql-general

From Lincoln Yeoh
Subject Re: A creepy story about dates. How to prevent it?
Date
Msg-id 5.2.1.1.1.20030624231310.02e373f0@mbox.jaring.my
Whole thread Raw
In response to Re: A creepy story about dates. How to prevent it?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: A creepy story about dates. How to prevent it?
Re: A creepy story about dates. How to prevent it?
List pgsql-general
At 03:24 PM 6/23/2003 -0400, Bruce Momjian wrote:

>Added to TODO, with question mark:
>
>         * Have initdb set DateStyle based on locale?

Given various issues with locale (indexes, ordering etc) I'd think that
having a DB follow the O/S locale should be special case and require
explicit configuration.

More so if certain locales are significantly slower than others which
seemed to be the case at least in recent memory.

What if a European DB backed website is hosted on a US server with English,
French and German data?

If apps/programs are talking to DBs more than people are then it may make
more sense to store things in an application friendly format e.g. (date =
YYYY-MM-DD, or seconds since epoch) format and having the app convert it
based on the user's preferences. After all even in English, apps may choose
to display Tuesday as T, Tue, Tuesday, or whatever the Boss wants.

Unless postgresql has special features allowing switching from one locale
to another on the fly (including indexes, ordering etc) within a DB
session, I'd rather stick to say the C locale, or whatever it is that's
fastest.

Another point of consideration: if someone accidentally loads
multibyte/other locale data into a C locale DB (or whatever is chosen as
default DB locale), would dumping the loaded data and reloading it into a
multibyte locale result in information/precision loss?

Link.

pgsql-general by date:

Previous
From: s
Date:
Subject: postgres 7.3.3 problem - not talking across port
Next
From: PeterKorman
Date:
Subject: Re: Running pg_dump under vcron