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

From Robert Haas
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id CA+TgmoYU=rFVk8dSQzL+no+ZAKKWSDigSugAyzy83g9skHXRzQ@mail.gmail.com
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
On Mon, Feb 14, 2022 at 12:25 PM Chapman Flack <chap@anastigmatix.net> wrote:
> On 02/14/22 11:43, Robert Haas wrote:
> > On Mon, Feb 14, 2022 at 10:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Robert Haas <robertmhaas@gmail.com> writes:
> >>> I don't particularly like Chapman's solution,
> > ... and (3) is an attempt at compromise that is nobody's first choice.
>
> Ok, I guess that's )sniffle( a pretty fair way of putting it.

I mean I like it better than Tom does ... I just think it's a
complicated work around for a problem we don't really need to have.

> My reading of past discussions on the list suggest that stronger
> encapsulation and API delineation have advocates in some quarters,
> so I tried to accommodate that in what I proposed. It does, for example,
> avoid exposing the 'real' value of a GUC to writing by a buggy
> or compromised extension.
>
> I'll be first to agree what I proposed isn't beautiful, but it might be
> that a round or two of improvement by somebody smarter than me could lead
> to something possibly preferable to PGDLLIMPORT-everywhere /when measured
> against certain objectives/, like encapsulation.
>
> So maybe this is in part a discussion about what the weights should be
> on those various objectives.

Keep in mind that there's nothing being set in stone here. Applying
PGDLLIMPORT to all GUCs across the board does not foreclose putting
some other system that restricts symbol visibility in the future. But
in the present, there is clearly no approach to the symbol visibility
problem that is fully baked or enjoys consensus. Yet, there is clearly
consensus that not being able to access GUCs in Windows extensions is
a problem. There must be like six different threads with people
complaining about that, and in every case the suggested solution is to
just add PGDLLIMPORT for crying out loud.

If in the future there is a consensus to restrict symbol visibility in
order to achieve some agreed-upon amount of encapsulation, then we can
do that then. Extension authors may not like it much, but every
serious extension author understands that the PostgreSQL code base
needs to keep moving forward, and that this will sometimes require
them to adjust for new major versions. This would be a bigger
adjustment than many, but I have confidence that if the benefits are
worthwhile, people will cope with it and adjust their extensions to
adhere to whatever new rules we put in place.

But between now and then, refusing to apply PGDLLIMPORT to a basically
random subset of GUCs is just annoying people without any compensating
benefit.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Next
From: Robert Haas
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT