Re: [HACKERS] Moving core timestamp typedefs/macros somewhere else

2011-09-09 Thread Tom Lane
I wrote:
 I propose moving the Timestamp/Interval typedefs, as well as some basic
 associated macros such as the ones mentioned above (basically, lines
 25-100 of utils/timestamp.h, plus the DT_NOBEGIN/DT_NOEND stuff, plus
 the Julian-date macros in datetime.h), into a separate header file that
 contains no backend-only declarations (eg, not fmgr.h stuff; right
 offhand I don't think it would depend on anything except c.h).

I've committed this patch, but there was one aspect that remains
unfinished.  I had hoped to remove the duplicative parts of ecpg's dt.h
header in favor of including datatype/timestamp.h, along the lines of
the attached patch.  However, while ecpg itself compiles with that
change, its test programs do not; apparently they include
pgtypes_timestamp.h without previously including anything that defines
typedef int32.  I'm unsure if there's a reasonable way to work around
that --- any thoughts?

regards, tom lane

*** src/interfaces/ecpg/include/pgtypes_timestamp.h.orig	Fri Sep  9 13:11:12 2011
--- src/interfaces/ecpg/include/pgtypes_timestamp.h	Fri Sep  9 13:08:18 2011
***
*** 6,18 
  /* pgtypes_interval.h includes ecpg_config.h */
  #include pgtypes_interval.h
  
! #ifdef HAVE_INT64_TIMESTAMP
! typedef int64 timestamp;
! typedef int64 TimestampTz;
! #else
! typedef double timestamp;
! typedef double TimestampTz;
! #endif
  
  #ifdef __cplusplus
  extern		C
--- 6,14 
  /* pgtypes_interval.h includes ecpg_config.h */
  #include pgtypes_interval.h
  
! #include datatype/timestamp.h
! 
! typedef TimestampTz timestamp;
  
  #ifdef __cplusplus
  extern		C
*** src/interfaces/ecpg/pgtypeslib/dt.h.orig	Fri Sep  9 13:11:12 2011
--- src/interfaces/ecpg/pgtypeslib/dt.h	Fri Sep  9 13:06:49 2011
***
*** 7,25 
  
  #define MAXTZLEN			 10
  
- #ifdef HAVE_INT64_TIMESTAMP
- 
- typedef int32 fsec_t;
- #else
- 
- typedef double fsec_t;
- 
- /* round off to MAX_TIMESTAMP_PRECISION decimal places */
- /* note: this is also used for rounding off intervals */
- #define TS_PREC_INV 100.0
- #define TSROUND(j) (rint(((double) (j)) * TS_PREC_INV) / TS_PREC_INV)
- #endif
- 
  #define USE_POSTGRES_DATES0
  #define USE_ISO_DATES	1
  #define USE_SQL_DATES	2
--- 7,12 
***
*** 243,278 
  } while(0)
  #endif
  
- /* in both timestamp.h and ecpg/dt.h */
- #define DAYS_PER_YEAR	365.25	/* assumes leap year every four years */
- #define MONTHS_PER_YEAR 12
- /*
-  *	DAYS_PER_MONTH is very imprecise.  The more accurate value is
-  *	365.2425/12 = 30.436875, or '30 days 10:29:06'.  Right now we only
-  *	return an integral number of days, but someday perhaps we should
-  *	also return a 'time' value to be used as well.	ISO 8601 suggests
-  *	30 days.
-  */
- #define DAYS_PER_MONTH	30		/* assumes exactly 30 days per month */
- #define HOURS_PER_DAY	24		/* assume no daylight savings time changes */
- 
- /*
-  *	This doesn't adjust for uneven daylight savings time intervals or leap
-  *	seconds, and it crudely estimates leap years.  A more accurate value
-  *	for days per years is 365.2422.
-  */
- #define SECS_PER_YEAR	(36525 * 864)	/* avoid floating-point computation */
- #define SECS_PER_DAY	86400
- #define SECS_PER_HOUR	3600
- #define SECS_PER_MINUTE 60
- #define MINS_PER_HOUR	60
- 
- #ifdef HAVE_INT64_TIMESTAMP
- #define USECS_PER_DAY	INT64CONST(864)
- #define USECS_PER_HOUR	INT64CONST(36)
- #define USECS_PER_MINUTE INT64CONST(6000)
- #define USECS_PER_SEC	INT64CONST(100)
- #endif
  
  /*
   * Date/time validation
--- 230,235 
***
*** 280,302 
   */
  #define isleap(y) (((y) % 4) == 0  (((y) % 100) != 0 || ((y) % 400) == 0))
  
- /* Julian date support for date2j() and j2date()
-  *
-  * IS_VALID_JULIAN checks the minimum date exactly, but is a bit sloppy
-  * about the maximum, since it's far enough out to not be especially
-  * interesting.
-  */
- 
- #define JULIAN_MINYEAR (-4713)
- #define JULIAN_MINMONTH (11)
- #define JULIAN_MINDAY (24)
- #define JULIAN_MAXYEAR (5874898)
- 
- #define IS_VALID_JULIAN(y,m,d) y)  JULIAN_MINYEAR) \
-   || (((y) == JULIAN_MINYEAR)  (((m)  JULIAN_MINMONTH) \
-   || (((m) == JULIAN_MINMONTH)  ((d) = JULIAN_MINDAY) \
-   ((y)  JULIAN_MAXYEAR))
- 
  #define UTIME_MINYEAR (1901)
  #define UTIME_MINMONTH (12)
  #define UTIME_MINDAY (14)
--- 237,242 
***
*** 311,336 
   || (((y) == UTIME_MAXYEAR)  (((m)  UTIME_MAXMONTH) \
|| (((m) == UTIME_MAXMONTH)  ((d) = UTIME_MAXDAY))
  
- #ifdef HAVE_INT64_TIMESTAMP
- 
- #define DT_NOBEGIN		(-INT64CONST(0x7fff) - 1)
- #define DT_NOEND		(INT64CONST(0x7fff))
- #else
- 
- #ifdef HUGE_VAL
- #define DT_NOBEGIN		(-HUGE_VAL)
- #define DT_NOEND		(HUGE_VAL)
- #else
- #define DT_NOBEGIN		(-DBL_MAX)
- #define DT_NOEND		(DBL_MAX)
- #endif
- #endif   /* HAVE_INT64_TIMESTAMP */
- 
- #define TIMESTAMP_NOBEGIN(j)	do {(j) = DT_NOBEGIN;} while (0)
- #define TIMESTAMP_NOEND(j)			do 

[HACKERS] Moving core timestamp typedefs/macros somewhere else

2011-09-07 Thread Tom Lane
In connection with doing this:
http://archives.postgresql.org/message-id/22214.1315343...@sss.pgh.pa.us
I've run into the problem that tz_acceptable(), which needs to be
available to frontend-ish code if initdb is to use it, depends on these
symbols:

#define UNIX_EPOCH_JDATE2440588 /* == date2j(1970, 1, 1) */
#define POSTGRES_EPOCH_JDATE2451545 /* == date2j(2000, 1, 1) */
#define SECS_PER_DAY 86400

which are defined in backend-only include files such as
utils/timestamp.h.  This immediately brought to mind the pgrminclude
fiasco of a couple days ago, which was at least in part due to the fact
that utils/timestamp.h got included into some very low-level header
files so that they could use typedef TimestampTz.  So I think it's time
to do something about that.

I propose moving the Timestamp/Interval typedefs, as well as some basic
associated macros such as the ones mentioned above (basically, lines
25-100 of utils/timestamp.h, plus the DT_NOBEGIN/DT_NOEND stuff, plus
the Julian-date macros in datetime.h), into a separate header file that
contains no backend-only declarations (eg, not fmgr.h stuff; right
offhand I don't think it would depend on anything except c.h).

If you believe the idea I suggested a few days ago that we ought to try
to push basic typedefs into a separate set of headers, then this could
be the first instance of that, which would lead to naming it something
like datatype/timestamp.h.  If that seems premature, then I guess it
ought to go into utils/, but then we need some other name because
utils/timestamp.h is taken.

Thoughts?

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Moving core timestamp typedefs/macros somewhere else

2011-09-07 Thread Brendan Jurd
On 8 September 2011 10:22, Tom Lane t...@sss.pgh.pa.us wrote:
 If you believe the idea I suggested a few days ago that we ought to try
 to push basic typedefs into a separate set of headers, then this could
 be the first instance of that, which would lead to naming it something
 like datatype/timestamp.h.  If that seems premature, then I guess it
 ought to go into utils/, but then we need some other name because
 utils/timestamp.h is taken.

The separate headers for basic typedefs makes perfect sense to me.

Cheers,
BJ

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers