AW: AW: AW: AW: Re: tinterval - operator problems on AI X
От | Zeugswetter Andreas SB |
---|---|
Тема | AW: AW: AW: AW: Re: tinterval - operator problems on AI X |
Дата | |
Msg-id | 11C1E6749A55D411A9670001FA6879633681C9@sdexcsrv1.f000.d0188.sd.spardat.at обсуждение исходный текст |
Ответы |
Re: AW: AW: AW: AW: Re: tinterval - operator problems on
AI X
|
Список | pgsql-hackers |
> The other category is run-time behaviour, which is the present case of > testing whether mktime() behaves a certain way when given certain > arguments. Another item that has been thrown around over the years is > whether the system supports Unix domain sockets (essentially a run-time > behaviour check of socket()). You do not need to check these things in > configure; you can just do it when the program runs and adjust > accordingly. I think in PostgreSQL there is also a third category: "features" that affect on disk storage of data. Those can definitely not be changed at runtime, because a change would corrupt that database. It is very hard to judge what "feature" really has an on disk effect. It can e.g. be an application that selected a row that was inserted before the feature existed, do some calculations and insert a new row with the feature now available. Thus I think available features should be as immune to OS feature changes as possible, but let us postpone that discussion until after 7.1 release. > So I would currently suggest that you define > > #ifdef AIX || IRIX > # define NO_DST_BEFORE_1970 > #endif That would be OK for me. Where do we put that ? Imho a good place would be config.h. One problem though is, that I don't have a patch, that really turns off DST before 1970 (which would be considerably more work). I only have a patch that makes platforms, that don't have a working mktime for values before 1970, behave like NO_DST_... Thus more wanting a #define NO_MKTIME_BEFORE_1970. Andreas
В списке pgsql-hackers по дате отправления: