From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Christian Ullrich <chris(at)chrullrich(dot)net>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>, buildfarm(at)sraoss(dot)co(dot)jp, dpage(at)postgresql(dot)org |
Subject: | Re: pg_config.h.win32 missing a set of flags from pg_config.h.in added in v11 development |
Date: | 2018-06-18 01:57:34 |
Message-ID: | 20180618015734.GB3721@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jun 17, 2018 at 10:57:16AM -0400, Tom Lane wrote:
> If we're just leaving them undefined, isn't this purely cosmetic?
> At least, that was what I understood to be the reasoning for leaving
> such symbols out of pg_config.h.win32 in the past.
>
> I'm on board with making things more consistent in HEAD, but not sure
> I see any need for back-patching.
I think that it is also important to give to those flags some
visibility so as packagers can more easily find what to switch on/off
when they come across compilation failures with a given version of
OpenSSL, so that's also a matter of documenting things. You are right
that as the number of people doing packaging on Windows for Postgres can
perhaps be counted with the fingers of both hands, that may not be worth
bothering. I maintain such stuff by the way, so this counts as one
finger up.
As there is visibly a consensus for HEAD, for now I propose to just
process with the previous patch on only the master branch then. This
will address the open item. Any objections to that?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-06-18 02:31:02 | Re: [bug fix] Cascaded standby cannot start after a clean shutdown |
Previous Message | Michael Paquier | 2018-06-18 01:50:48 | Re: [bug fix] Cascaded standby cannot start after a clean shutdown |