Re: AW: AW: AW: Re: tinterval - operator problems on AIX - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: AW: AW: AW: Re: tinterval - operator problems on AIX
Date
Msg-id 3A68977C.F7F88509@alumni.caltech.edu
Whole thread Raw
In response to Re: AW: AW: AW: Re: tinterval - operator problems on AIX  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: AW: AW: AW: Re: tinterval - operator problems on AIX  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
> Exactly.  What if someone has a binary PostgreSQL package installed, then
> updates his time library to something supposedly binary compatible and
> finds out that PostgreSQL still doesn't use the enhanced capabilities?
> Runtime behaviour checks are done at runtime, it's as simple as that.

I'm not sure I fully appreciate the distinction here. configure will
check for "behavior" of various kinds, including "behavior assumptions"
in the PostgreSQL code.

So the issue for this case is simply whether it is appropriate to check
for behavior at run time on all platforms, even those known to "never"
exhibit this problematic result, or whether we put in a configure-time
check to save the day for the (two) platforms known to have trouble --
without the other supported platforms taking the hit by having to check
even though the check will never fail.

Andreas, Pete and I were advocating the latter view: that the majority
of platforms which happen to be well behaved should run code optimized
for them, while the bad actors can be supported without "#ifdef __AIX__
|| __IRIX__" in our code, but rather with a more helpful "#ifdef
NO_DST_BEFORE_1970" or whatever.
                   - Thomas


pgsql-hackers by date:

Previous
From: Ian Lance Taylor
Date:
Subject: Re: Re: [PATCHES] s_lock.h cleanup
Next
From: "Martin A. Marques"
Date:
Subject: Re: [GENERAL] re-instalation