Re: PostmasterPid not marked with PGDLLIMPORT
| От | David G. Johnston |
|---|---|
| Тема | Re: PostmasterPid not marked with PGDLLIMPORT |
| Дата | |
| Msg-id | CAKFQuwYopZEhThkBQ38Py8EKks0uORoi05vRoiSsv+WDHqu5Aw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: PostmasterPid not marked with PGDLLIMPORT (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: PostmasterPid not marked with PGDLLIMPORT
(Robert Haas <robertmhaas@gmail.com>)
|
| Список | pgsql-hackers |
> On Wed, Jun 1, 2016 at 5:04 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> 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.
I suggest that there's a more principled reason for refusing a back-patch
here, which is that we don't back-patch new features, only bug fixes.
This request is certainly not a bug fix. It's in support of a new feature
--- and one that's not even ours, but a third-party extension.
Maybe I don't understand PGDLLEXPORT...
The PostgreSQL function/feature in question is already in place and can be accessed by someone using Linux or other unix-like variant. But it cannot be access by our Window's users because we failed to add a PGDLLEXPORT somewhere. If it is our goal to treat Windows and Linux/Unix equally then that discrepancy is on its face a bug. The fact we don't catch these until some third-party points it out doesn't make it any less a bug.
Considering that said extension isn't finished yet, it's hard to guess
whether this will be the only blocking factor preventing it from working
with older versions, but it might well be that there are other problems.
From my prior point the reason someone wants to use the unexposed but documented public API shouldn't matter.
Also, even if it would work, the author would be reduced to saying things
like "it will work in 9.4, if it's 9.4.9 or later". Keeping track of that
level of detail is no fun either for the author or for users.
This seems hollow. "It works on the latest version of all officially supported PostgreSQL releases" is a reasonable policy for a third-party application to take. That it might work on older releases would be a bonus for some new users.
It'd be
a lot simpler all around to just say "my spiffy new extension requires 9.6
or later".
And it makes the available user base considerably smaller. A small change to get the other 80% of the users is something to take seriously.
In short, I'd vote for putting this change in HEAD, but I see no need to
back-patch.
I see a need for back-patching and no technical reason why it cannot be done - easily.
David J.
В списке pgsql-hackers по дате отправления: