Re: Australian timezone configure option
От | Bruce Momjian |
---|---|
Тема | Re: Australian timezone configure option |
Дата | |
Msg-id | 200106121521.f5CFLGi10737@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Australian timezone configure option (Chris Dunlop <chris@onthe.net.au>) |
Список | pgsql-patches |
> (moved to -hackers list, since this is a *feature change* which should > not just be discussed in -patches) > > >>I have decided to make this configurable via postgresql.conf so you > >>don't need separate binaries / configure switch to run in Australia. > >>I will send a patch over for testing. > > We will not be adding this to 7.1.X though you are free to use it in > > that version. It will appear in 7.2. > > Um, er... > > I'm not particularly happy about the solution, and would like to not see > it in the main source code without further discussion. Sorry I was out > of town for the extensive two hour discussion on the topic ;) > > One could categorize the "Australian problem" as an example of a > localization, and brute-force calls to work around it are a step in the > wrong direction imho. Particularly since Australia contributes fully 25% > of the time zone information in our lookup table, including multiple > synonyms for several time zones. Just as we might want to send a message > to M$ that their SQL hacks are not acceptable, we should send a message > to Australia that playing fast and loose with time zone names should not > be tolerated. Hmm, and while we are at it we should do something about > world hunger and arms race issues. Patches coming soon ;) ;) > > OK, those last few sentences were not serious. But, I would like a > solution that starts to address long-term issues in time zone support. > > Before hacking the rather carefully evolved static tables let's consider > how to support time localization generally (e.g. language-specific names > for months). In the meantime, a compile-time solution for more easily > setting the "CST" interpretation would seem to be an incremental > improvement for "buildability" (and this has already been submitted). > > How about implementing an optional db table-based approach for this > lookup and the other localized info? If it were a compile-time option we > could evaluate the performance impact and allow folks to trade > performance vs features. And perhaps (later, much later. Weeks later... > ;) that choice could be a GUC parameter. Comments? This is way beyond where I want to go with the Australian stuff and I have not seen much demand from users for more than a GUC option. Australians wanted a 'configure' flag, I made it GUC which gets reloaded on first call and can later be assigned to a GUC hook when we get those. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-patches по дате отправления: