> (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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
In response to
pgsql-hackers by date
|Next:||From: Robert Forsman||Date: 2001-06-12 15:37:37|
|Subject: freaky results|
|Previous:||From: Tom Lane||Date: 2001-06-12 15:19:36|
|Subject: Re: inet/cidr wierdness (casting) |
pgsql-patches by date
|Next:||From: Bruce Momjian||Date: 2001-06-12 15:56:12|
|Subject: Re: Patch to include PAM support...|
|Previous:||From: Bruce Momjian||Date: 2001-06-12 15:18:29|
|Subject: Re: Australian timezone configure option|