Good point. ---------------------------------------------------------------------------
scott.marlowe wrote: > I thought it was more correctly we were considering not using the the > system locale automatically, but that if someone wished to use > --locale=en_US we'd let that work, right? > > I would assume that if someone actually went to the bother of setting a > locale, then it should be the deciding factor in how we handle dates, et. > al. > > On Tue, 24 Jun 2003, Bruce Momjian wrote: > > > > > 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
