From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | lockhart(at)fourpalms(dot)org |
Cc: | Chris Dunlop <chris(at)onthe(dot)net(dot)au>, pgsql-patches(at)postgresql(dot)org, Hackers List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Australian timezone configure option |
Date: | 2001-06-12 15:21:16 |
Message-ID: | 200106121521.f5CFLGi10737@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers 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(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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Forsman | 2001-06-12 15:37:37 | freaky results |
Previous Message | Tom Lane | 2001-06-12 15:19:36 | Re: inet/cidr wierdness (casting) |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-06-12 15:56:12 | Re: Patch to include PAM support... |
Previous Message | Bruce Momjian | 2001-06-12 15:18:29 | Re: Australian timezone configure option |