Re: [COMMITTERS] pgsql: Fix bool/int type confusion

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [COMMITTERS] pgsql: Fix bool/int type confusion
Date: 2017-09-21 18:58:09
Message-ID: 27597.1506020289@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 9/21/17 11:46, Tom Lane wrote:
>> This also means that the portability problem is purely hypothetical;
>> given valid tz reference data the code wouldn't ever try to increment
>> "hit" to 2 anyway. It's even more hypothetical for us, because we don't
>> use leap-second-aware zones.

> It's not so much that there is an actual portability problem. The
> problem is that the compiler issues a warning for this with stdbool.

Understood.

>> Therefore, what I would like to do is revert this commit (0ec2e908b),
>> and then either leave the problem to be fixed by our next regular sync
>> with a released tzcode version, or else force a sync with their git tip
>> to absorb their fix now. In either case we should keep all our live
>> branches in sync. I'm willing to do the code-sync work either way.

> That makes sense. There is no urgency on the stdbool patch set, so
> waiting for this to be resolved properly around November seems reasonable.

I've just been going through their git commit log to see what else has
changed since tzcode2017b, and I note that there are half a dozen other
portability-ish fixes. I think that some of them affect only code we
don't use, but I'm not sure that that's the case for all. So I'm a bit
inclined to go with plan B, that is sync with their current HEAD now.
As far as I've been able to tell, they don't have any special code QA
process that they apply before a release. They push out releases based
on the need to update the tzdata files, and the tzcode just rides along
with that in whatever state it is in. So there's not really any
reliability gain from waiting for an official code release --- it just
is a bit easier to document what we synced to. That being the case,
absorbing their changes in smaller chunks rather than bigger ones seems
easier. I don't have the sync process totally automated, but it's not
that painful as long as there are not too many changes at once.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2017-09-21 22:13:56 pgsql: Give a better error for duplicate entries in VACUUM/ANALYZE colu
Previous Message Peter Eisentraut 2017-09-21 18:23:27 Re: [COMMITTERS] pgsql: Fix bool/int type confusion

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-09-21 19:12:35 Re: ICU locales and text/char(n) SortSupport on Windows
Previous Message Peter Eisentraut 2017-09-21 18:44:17 Re: !USE_WIDE_UPPER_LOWER compile errors in v10+