Re: Mark all GUC variable as PGDLLIMPORT
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <bruce@momjian.us>, Julien Rouhaud <rjuju123@gmail.com>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-08-23T18:30:57Z
Lists: pgsql-hackers
On Mon, Aug 23, 2021 at 11:40 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > In that case, why not improve the API with functions that return the > values in some native datatype? For scalars with native C types (int, > floats, Boolean etc) this is easy enough; I bet it'll solve 99% of the > problems or more. Sure, but ... why bother? The entire argument rests on the presumption that there is some harm being done by people accessing the values directly, but I don't think that's true. And, if it were true, it seems likely that this proposed API would have the exact same problem, because it would let people do exactly the same thing. And, going through this proposed API would still be significantly more expensive than just accessing the bare variables, because you'd at least have to do some kind of lookup based on the GUC name to find the corresponding variable. It's just a solution in search of a problem. Nothing bad happens when people write extensions that access GUC variables directly. It works totally, completely fine. Except on Windows. -- Robert Haas EDB: http://www.enterprisedb.com
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