Replace time_t with pg_time_t (same values, but always int64) in on-disk

data structures and backend internal APIs.  This solves problems we've seen
recently with inconsistent layout of pg_control between machines that have
32-bit time_t and those that have already migrated to 64-bit time_t.  Also,
we can get out from under the problem that Windows' Unix-API emulation is not
consistent about the width of time_t.

There are a few remaining places where local time_t variables are used to hold
the current or recent result of time(NULL).  I didn't bother changing these
since they do not affect any cross-module APIs and surely all platforms will
have 64-bit time_t before overflow becomes an actual risk.  time_t should
be avoided for anything visible to extension modules, however.

1 files changed, 6 insertions, 4 deletions

diff --git a/src/backend/utils/adt/datetime.c b/src/backend/utils/adt/datetime.c
index ed411cf21af..0bfdd0ec2d6 100644
--- a/src/backend/utils/adt/datetime.c
+++ b/src/backend/utils/adt/datetime.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/utils/adt/datetime.c,v 1.184 2008/01/01 19:45:52 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/utils/adt/datetime.c,v 1.185 2008/02/17 02:09:28 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -650,9 +650,11 @@ ParseDateTime(const char *timestr, char *workbuf, size_t buflen,
  *				"20011225T040506.789-07"
  *
  * Use the system-provided functions to get the current time zone
- *	if not specified in the input string.
- * If the date is outside the time_t system-supported time range,
- *	then assume UTC time zone. - thomas 1997-05-27
+ * if not specified in the input string.
+ *
+ * If the date is outside the range of pg_time_t (in practice that could only
+ * happen if pg_time_t is just 32 bits), then assume UTC time zone - thomas
+ * 1997-05-27
  */
 int
 DecodeDateTime(char **field, int *ftype, int nf,