AW: AW: AW: AW: Re: tinterval - operator problems on AI X

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Peter Eisentraut'" <peter_e(at)gmx(dot)net>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: Pete Forman <pete(dot)forman(at)westerngeco(dot)com>, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, lockhart(at)fourpalms(dot)org, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: AW: AW: AW: AW: Re: tinterval - operator problems on AI X
Date: 2001-01-22 10:07:07
Message-ID: 11C1E6749A55D411A9670001FA6879633681C9@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Patrick Welche 2001-01-22 10:29:33 Strange..
Previous Message Magnus Hagander 2001-01-22 08:45:24 FW: Postgresql on win32