Re: Mark all GUC variable as PGDLLIMPORT

Andres Freund <andres@anarazel.de> writes:
> On 2022-02-13 15:36:16 -0500, Chapman Flack wrote:
>> Also, I think there are some options that are only represented by
>> an int, float8, etc., when shown, but whose native internal form
>> is something else, like a struct. I was definitely contemplating
>> that you could 'subscribe' to one of those too, by passing the
>> address of an appropriate struct. But of course a GetConfigOption()
>> flavor could work that way too.

> I have a very hard time seeing a use-case for this. Nor how it'd even work
> with a struct - you can't just copy the struct contents, because of pointers
> to objects etc.  I don't think there really are options like this anyway.

There are a couple of legacy cases like "datestyle" where something
that the user sees as one GUC translates to multiple variables under
the hood, so you'd have to invent a struct if you wanted to pass
them through a mechanism like this.  I don't have a big problem
with leaving those out of any such solution, though.  (I see that
datestyle's underlying variables DateStyle and DateOrder are already
marked PGDLLIMPORT, and that's fine with me.)  A possibly more
interesting case is something like search_path --- but again,
there are already special-purpose APIs for accessing the interpreted
value of that.

			regards, tom lane