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 Hagander

1 files changed, 27 insertions, 81 deletions

diff --git a/src/backend/commands/variable.c b/src/backend/commands/variable.c
index 7add658d6ab..e7762040626 100644
--- a/src/backend/commands/variable.c
+++ b/src/backend/commands/variable.c
@@ -9,7 +9,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/commands/variable.c,v 1.105 2004/12/31 21:59:42 pgsql Exp $
+ *	  $PostgreSQL: pgsql/src/backend/commands/variable.c,v 1.106 2005/04/19 03:13:58 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -315,13 +315,13 @@ assign_timezone(const char *value, bool doit, GucSource source)
 			 * UNKNOWN as the canonical spelling.
 			 *
 			 * During GUC initialization, since the timezone library isn't
-			 * set up yet, pg_get_current_timezone will return NULL and we
+			 * set up yet, pg_get_timezone_name will return NULL and we
 			 * will leave the setting as UNKNOWN.  If this isn't
 			 * overridden from the config file then
 			 * pg_timezone_initialize() will eventually select a default
 			 * value from the environment.
 			 */
-			const char *curzone = pg_get_current_timezone();
+			const char *curzone = pg_get_timezone_name(global_timezone);
 
 			if (curzone)
 				value = curzone;
@@ -329,90 +329,36 @@ assign_timezone(const char *value, bool doit, GucSource source)
 		else
 		{
 			/*
-			 * Otherwise assume it is a timezone name.
-			 *
-			 * We have to actually apply the change before we can have any
-			 * hope of checking it.  So, save the old value in case we
-			 * have to back out.  We have to copy since
-			 * pg_get_current_timezone returns a pointer to its static
-			 * state.
-			 *
-			 * This would all get a lot simpler if the TZ library had a
-			 * better API that would let us look up and test a timezone
-			 * name without making it the default.
+			 * Otherwise assume it is a timezone name, and try to load it.
 			 */
-			const char *cur_tz;
-			char	   *save_tz;
-			bool		known,
-						acceptable;
+			pg_tz *new_tz;
 
-			cur_tz = pg_get_current_timezone();
-			if (cur_tz)
-				save_tz = pstrdup(cur_tz);
-			else
-				save_tz = NULL;
+			new_tz = pg_tzset(value);
 
-			known = pg_tzset(value);
-			acceptable = known ? tz_acceptable() : false;
+			if (!new_tz)
+			{
+				ereport((source >= PGC_S_INTERACTIVE) ? ERROR : LOG,
+						(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+						 errmsg("unrecognized time zone name: \"%s\"",
+								value)));
+				return NULL;
+			}
 
-			if (doit && known && acceptable)
+			if (!tz_acceptable(new_tz))
 			{
-				/* Keep the changed TZ */
-				HasCTZSet = false;
+				ereport((source >= PGC_S_INTERACTIVE) ? ERROR : LOG,
+						(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+						 errmsg("time zone \"%s\" appears to use leap seconds",
+								value),
+						 errdetail("PostgreSQL does not support leap seconds.")));
+				return NULL;
 			}
-			else
+
+			if (doit)
 			{
-				/*
-				 * Revert to prior TZ setting; note we haven't changed
-				 * HasCTZSet in this path, so if we were previously using
-				 * a fixed offset, we still are.
-				 */
-				if (save_tz)
-					pg_tzset(save_tz);
-				else
-				{
-					/*
-					 * TZ library wasn't initialized yet.  Annoyingly, we
-					 * will come here during startup because guc-file.l
-					 * checks the value with doit = false before actually
-					 * applying. The best approach seems to be as follows:
-					 *
-					 * 1. known && acceptable: leave the setting in place,
-					 * since we'll apply it soon anyway.  This is mainly
-					 * so that any log messages printed during this
-					 * interval are timestamped with the user's requested
-					 * timezone.
-					 *
-					 * 2. known && !acceptable: revert to GMT for lack of any
-					 * better idea.  (select_default_timezone() may get
-					 * called later to undo this.)
-					 *
-					 * 3. !known: no need to do anything since TZ library did
-					 * not change its state.
-					 *
-					 * Again, this should all go away sometime soon.
-					 */
-					if (known && !acceptable)
-						pg_tzset("GMT");
-				}
-				/* Complain if it was bad */
-				if (!known)
-				{
-					ereport((source >= PGC_S_INTERACTIVE) ? ERROR : LOG,
-							(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
-							 errmsg("unrecognized time zone name: \"%s\"",
-									value)));
-					return NULL;
-				}
-				if (!acceptable)
-				{
-					ereport((source >= PGC_S_INTERACTIVE) ? ERROR : LOG,
-							(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
-					errmsg("time zone \"%s\" appears to use leap seconds",
-						   value),
-							 errdetail("PostgreSQL does not support leap seconds.")));
-					return NULL;
-				}
+				/* Save the changed TZ */
+				global_timezone = new_tz;
+				HasCTZSet = false;
 			}
 		}
 	}
@@ -459,7 +405,7 @@ show_timezone(void)
 										  IntervalPGetDatum(&interval)));
 	}
 	else
-		tzn = pg_get_current_timezone();
+		tzn = pg_get_timezone_name(global_timezone);
 
 	if (tzn != NULL)
 		return tzn;