Re: AW: AW: AW: Re: tinterval - operator problems on AIX

Поиск
Список
Период
Сортировка
От Thomas Lockhart
Тема Re: AW: AW: AW: Re: tinterval - operator problems on AIX
Дата
Msg-id 3A68977C.F7F88509@alumni.caltech.edu
обсуждение исходный текст
Ответ на Re: AW: AW: AW: Re: tinterval - operator problems on AIX  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: AW: AW: AW: Re: tinterval - operator problems on AIX  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Ian Lance Taylor
Дата:
Сообщение: Re: Re: [PATCHES] s_lock.h cleanup
Следующее
От: "Martin A. Marques"
Дата:
Сообщение: Re: [GENERAL] re-instalation