Thread: Getting rid of the global timezone

Getting rid of the global timezone

From
"Magnus Hagander"
Date:
Hello!

Attached patch gets rid of the global timezone in the following steps:

* Changes the APIs to the timezone functions to take a pg_tz pointer as
an argument, representing the timezone to use for the selected
operation.

* Adds a global_timezone variable that represents the current timezone
in the backend as set by SET TIMEZONE (or guc, or env, etc).

* Implements a hash-table cache of loaded tables, so we don't have to
read and parse the TZ file everytime we change a timezone. While not
necesasry now (we don't change timezones very often), I beleive this
will be necessary (or at least good) when "multiple timezones in the
same query" is eventually implemented. And code-wise, this was the time
to do it.


There are no user-visible changes at this time. Implementing the
"multiple zones in one query" is a later step...

This also gets rid of some of the cruft needed to "back out a timezone
change", since we previously couldn't check a timezone unless it was
activated first.

Passes regression tests on win32, linux (slackware 10) and solaris x86.

/Magnus

Attachment

Re: Getting rid of the global timezone

From
Bruce Momjian
Date:
Patch applied.  Thanks.  Sorry for the delay in applying.

---------------------------------------------------------------------------


Magnus Hagander wrote:
> Hello!
>
> Attached patch gets rid of the global timezone in the following steps:
>
> * Changes the APIs to the timezone functions to take a pg_tz pointer as
> an argument, representing the timezone to use for the selected
> operation.
>
> * Adds a global_timezone variable that represents the current timezone
> in the backend as set by SET TIMEZONE (or guc, or env, etc).
>
> * Implements a hash-table cache of loaded tables, so we don't have to
> read and parse the TZ file everytime we change a timezone. While not
> necesasry now (we don't change timezones very often), I beleive this
> will be necessary (or at least good) when "multiple timezones in the
> same query" is eventually implemented. And code-wise, this was the time
> to do it.
>
>
> There are no user-visible changes at this time. Implementing the
> "multiple zones in one query" is a later step...
>
> This also gets rid of some of the cruft needed to "back out a timezone
> change", since we previously couldn't check a timezone unless it was
> activated first.
>
> Passes regression tests on win32, linux (slackware 10) and solaris x86.
>
> /Magnus

Content-Description: tz.patch

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073