Horton

Thread

Commits

  1. Simplify PGAC_STRUCT_TIMEZONE Autoconf macro

  2. Integrate src/timezone library for all platforms. There is more we can

  1. Revert back to standard AC_STRUCT_TIMEZONE Autoconf macro

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2019-09-30T19:17:50Z

    Instead of AC_STRUCT_TIMEZONE we use our own variant called
PGAC_STRUCT_TIMEZONE that checks for tzname even if other variants were
found first.  But since 63bd0db12199c5df043e1dea0f2b574f622b3a4c we
don't use tzname anymore, so we don't need this anymore.

The attached patches revert back to the standard AC_STRUCT_TIMEZONE
macro and do some related cleanup.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  2. Re: Revert back to standard AC_STRUCT_TIMEZONE Autoconf macro

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-09-30T19:36:11Z

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> Instead of AC_STRUCT_TIMEZONE we use our own variant called
> PGAC_STRUCT_TIMEZONE that checks for tzname even if other variants were
> found first.  But since 63bd0db12199c5df043e1dea0f2b574f622b3a4c we
> don't use tzname anymore, so we don't need this anymore.

Hmm.  I wonder if we need AC_STRUCT_TIMEZONE either?  Seems like
we should only be using our own struct pg_tm.  If we could get
rid of that configure macro altogether, we could remove some dubious
junk like plpython.h's "#undef HAVE_TZNAME".

			regards, tom lane

  3. Re: Revert back to standard AC_STRUCT_TIMEZONE Autoconf macro

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2019-10-02T05:30:43Z

    On 2019-09-30 21:36, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> Instead of AC_STRUCT_TIMEZONE we use our own variant called
>> PGAC_STRUCT_TIMEZONE that checks for tzname even if other variants were
>> found first.  But since 63bd0db12199c5df043e1dea0f2b574f622b3a4c we
>> don't use tzname anymore, so we don't need this anymore.
> 
> Hmm.  I wonder if we need AC_STRUCT_TIMEZONE either?  Seems like
> we should only be using our own struct pg_tm.

There are a few places that seem to need it, such as initdb/findtimezone.c.

> If we could get
> rid of that configure macro altogether, we could remove some dubious
> junk like plpython.h's "#undef HAVE_TZNAME".

We could keep just the part of AC_STRUCT_TIMEZONE that we need, namely
the check for tm_zone, and remove the part about tzname.

New patch attached.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  4. Re: Revert back to standard AC_STRUCT_TIMEZONE Autoconf macro

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2019-10-07T14:55:58Z

    On 2019-10-02 07:30, Peter Eisentraut wrote:
> On 2019-09-30 21:36, Tom Lane wrote:
>> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>>> Instead of AC_STRUCT_TIMEZONE we use our own variant called
>>> PGAC_STRUCT_TIMEZONE that checks for tzname even if other variants were
>>> found first.  But since 63bd0db12199c5df043e1dea0f2b574f622b3a4c we
>>> don't use tzname anymore, so we don't need this anymore.
>>
>> Hmm.  I wonder if we need AC_STRUCT_TIMEZONE either?  Seems like
>> we should only be using our own struct pg_tm.
> 
> There are a few places that seem to need it, such as initdb/findtimezone.c.
> 
>> If we could get
>> rid of that configure macro altogether, we could remove some dubious
>> junk like plpython.h's "#undef HAVE_TZNAME".
> 
> We could keep just the part of AC_STRUCT_TIMEZONE that we need, namely
> the check for tm_zone, and remove the part about tzname.
> 
> New patch attached.

committed

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services