Re: pgsql: Default to hidden visibility for extension libraries where possi
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Date: 2022-07-19T14:28:07Z
Lists: pgsql-hackers
Attachments
- 0001-add-PGDLLEXPORTS-to-plpgsql.patch (text/x-diff)
[ Redirecting thread to -hackers from -committers ] On 2022-Jul-19, Tom Lane wrote: > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > > Do you just need to send a patch to add an exports.txt file to > > src/pl/plpgsql/src/ for these functions? > > The precedent of plpython says that PGDLLEXPORT markers are sufficient. > But yeah, we need a list of exactly which functions need to be > re-exposed. I imagine pldebugger has its own needs. A reasonable guess. I went as far as downloading pldebugger and compiling it, but it doesn't have a test suite of its own, so I couldn't verify anything about it. I did notice that plpgsql_check is calling function load_external_function(), and that doesn't appear in pldebugger. I wonder if the find_rendezvous_variable business is at play. Anyway, the minimal patch that makes plpgsql_check tests pass is attached. This seems a bit random. Maybe it'd be better to have a plpgsql_internal.h with functions that are exported only for plpgsql itself, and keep plpgsql.h with a set of functions, all marked PGDLLEXPORT, that are for external use. ... oh, and: $ postmaster -c shared_preload_libraries=plugin_debugger 2022-07-19 16:27:24.006 CEST [742142] FATAL: cannot request additional shared memory outside shmem_request_hook -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Commits
-
Add PGDLLEXPORTS to some plpgsql function declarations
- 1caf915ff31e 16.0 landed
-
Default to hidden visibility for extension libraries where possible
- 089480c07705 16.0 cited
-
Expose a few more PL/pgSQL functions to debugger plugins.
- 53ef6c40f1e7 15.0 cited