Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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                        |
  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 ForsmanDate: 2001-06-12 15:37:37
Subject: freaky results
Previous:From: Tom LaneDate: 2001-06-12 15:19:36
Subject: Re: inet/cidr wierdness (casting)

pgsql-patches by date

Next:From: Bruce MomjianDate: 2001-06-12 15:56:12
Subject: Re: Patch to include PAM support...
Previous:From: Bruce MomjianDate: 2001-06-12 15:18:29
Subject: Re: Australian timezone configure option

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group