Re: A creepy story about dates. How to prevent it?
От | Bruce Momjian |
---|---|
Тема | Re: A creepy story about dates. How to prevent it? |
Дата | |
Msg-id | 200306241902.h5OJ2Kk16042@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: A creepy story about dates. How to prevent it? (Lincoln Yeoh <lyeoh@pop.jaring.my>) |
Ответы |
Re: A creepy story about dates. How to prevent it?
|
Список | pgsql-general |
We are actually considering not honoring locale for initdb encodings, so it might make no sense to do this --- that another reason for the question mark, but until we decide, it is an open issue. --------------------------------------------------------------------------- Lincoln Yeoh wrote: > 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. > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-general по дате отправления: