Moving core timestamp typedefs/macros somewhere else

Lists: pgsql-hackers
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Moving core timestamp typedefs/macros somewhere else
Date: 2011-09-08 00:22:44
Message-ID: 9232.1315441364@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

In connection with doing this:
http://archives.postgresql.org/message-id/22214.1315343818@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_JDATE 2440588 /* == date2j(1970, 1, 1) */
#define POSTGRES_EPOCH_JDATE 2451545 /* == 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


From: Brendan Jurd <direvus(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Moving core timestamp typedefs/macros somewhere else
Date: 2011-09-08 00:35:11
Message-ID: CADxJZo2N4eNGx5oydnMUzYac4-FQKUb5oAEvhzTF4CSAfOWzEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 8 September 2011 10:22, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Meskes <meskes(at)postgresql(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Moving core timestamp typedefs/macros somewhere else
Date: 2011-09-09 17:30:57
Message-ID: 14438.1315589457@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

Attachment Content-Type Size
ecpg-use-datatype-timestamp-h.patch text/x-patch 4.3 KB