From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostmasterPid not marked with PGDLLIMPORT |
Date: | 2016-06-01 21:04:06 |
Message-ID: | CA+Tgmob8Lujwqr2AO+2RuKGho_YddG_tSeHyM1=RPbZALH2zfQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 1, 2016 at 12:24 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Robert Haas wrote:
>> On Wed, Jun 1, 2016 at 12:06 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>> > On 1 June 2016 at 11:48, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
>> >> Could it be possible to mark PostmasterPid with PGDLLIMPORT on HEAD
>> >> and back-branches?
>> >
>> > Sounds sensible to me.
>>
>> I don't really want to set a precedent that we'll back-patch
>> PGDLLIMPORT markings every time somebody needs a new symbol for some
>> extension they are writing, but I don't mind changing this in master.
>
> I wonder why is that -- just to reduce the commit load? I don't think
> this kind of change is likely to break anything, is it?
Probably not, but yes, I do want to reduce the commit load. I also
think that we essentially have a contract with our users to limit what
we back-patch to critical bug fixes and security fixes. When we don't
do that, people start asking to have individual fixes cherry-picked
instead of just upgrading, and that's not good. We may know that such
changes are low-risk, but that doesn't mean everyone else does.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2016-06-01 21:08:53 | Typo in comment in nbtree.h |
Previous Message | Tom Lane | 2016-06-01 18:52:05 | Re: Floating point comparison inconsistencies of the geometric types |