Re: Mark all GUC variable as PGDLLIMPORT
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Chapman Flack <chap@anastigmatix.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Julien Rouhaud <rjuju123@gmail.com>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers@lists.postgresql.org
Date: 2022-02-13T20:48:18Z
Lists: pgsql-hackers
Hi, On 2022-02-13 15:36:16 -0500, Chapman Flack wrote: > Clearly I'm not thinking here of the GUCs that are read-only views of > values that are determined some other way. How many of those are there > that are mutable, and could have their values changed without going > through the GUC mechanisms? Is there any GUCs where one needs this? There are a few GUCs frequently changing values, but it's stuff like transaction_read_only. Where I don't really see a use for constantly checking the value. > 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. Greetings, Andres Freund
Commits
-
Remove PGDLLIMPORT marker from __pg_log_level
- 8d3341266508 15.0 landed
-
Mark a few 'bbsink' related functions / variables static.
- b5f44225b833 15.0 landed
-
Add some missing PGDLLIMPORT markings
- 5edeb574285e 15.0 landed
-
Apply PGDLLIMPORT markings broadly.
- 8ec569479fc2 15.0 landed
-
Helper script to apply PGDLLIMPORT markings.
- 80900d469091 15.0 landed
-
Simplify declaring variables exported from libpgcommon and libpgport.
- e04a8059a74c 15.0 cited