Re: Mark all GUC variable as PGDLLIMPORT - Mailing list pgsql-hackers

From Chapman Flack
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id 61255F6E.5040109@anastigmatix.net
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Mark all GUC variable as PGDLLIMPORT  (Noah Misch <noah@leadboat.com>)
Re: Mark all GUC variable as PGDLLIMPORT  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 08/24/21 16:31, Robert Haas wrote:

> about adding PGDLLIMPORT, which ought to be totally uncontroversial,

The thing is, I think I have somewhere a list of all the threads on this
topic that I've read through since the first time I had to come with my own
hat in hand asking for a PGDLLIMPORT on something, years ago now, and
I don't think I have ever seen one where it was as uncontroversial
as you suggest.

In each iteration, I think I've also seen a countervailing view expressed
in favor of looking into whether globals visibility could be further
/reduced/. Maybe that view is slowly losing adherents? I don't know; it
did get advanced again by some in this thread.

The positions seem to routinely fall into two boxes:

* Let's look into that, it would be a step toward having a more defined API

* No, what we have now is so far from a defined API that there's nothing
  worth stepping toward.

The situation seems intermediate to me. The current condition is clearly
something that organically grew without a strong emphasis on defining API.

On the other hand, there are many corners of it that show evidence of
thought about encapsulation and API by the developers of those corners.

It seems to me like the kind of setting where incrementalists can find
room for small moves.

Regards,
-Chap



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Next
From: Bruce Momjian
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT