Thread: Re: [PATCHES] Australian timezone configure option
(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?
- Thomas
> (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
Thomas Lockhart writes: > 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). I'm not particularly happy about "popularizing" that compile time option beyond its current state (i.e., get in and edit config.h), and there's a reason why I haven't done it myself yet. --enable-xxx type configure options should, as a matter of principle, not replace one behaviour by another. (The proposed option replaces U.S. rules by Australian rules.) In this case it might look like a minor issue, but it's a slippery slope. For one thing, packages build by Australians will cease to behave reasonably in the rest of the world. That is the same reason why we don't want people altering NAMEDATALEN and BLCKSZ from configure. A run-time option seems like the appropriate solution. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> Thomas Lockhart writes: > > > 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). > > I'm not particularly happy about "popularizing" that compile time option > beyond its current state (i.e., get in and edit config.h), and there's a > reason why I haven't done it myself yet. > > --enable-xxx type configure options should, as a matter of principle, not > replace one behaviour by another. (The proposed option replaces U.S. > rules by Australian rules.) In this case it might look like a minor > issue, but it's a slippery slope. For one thing, packages build by > Australians will cease to behave reasonably in the rest of the world. > That is the same reason why we don't want people altering NAMEDATALEN and > BLCKSZ from configure. > > A run-time option seems like the appropriate solution. Agreed. Compile-time is just the wrong way to go. We should have compile-time stuff that just relates to the OS/compiler and sometimes installed software, or simply stuff that just can't be changed without a recompile/initdb like NAMEDATALEN. -- 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, Pennsylvania19026