mirror of
https://github.com/postgres/postgres.git
synced 2025-06-13 07:41:39 +03:00
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.
This commit is contained in:
@ -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,
|
||||
|
Reference in New Issue
Block a user