Re: Australian timezone configure option

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

In response to

Browse pgsql-hackers by date

  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)

Browse pgsql-patches by date

  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