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
|
Список | 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 по дате отправления: