Re: pgsql: Default to hidden visibility for extension libraries where possi
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Dave Page <dpage@postgresql.org>, Andres Freund <andres@anarazel.de>,
Pavel Stehule <pavel.stehule@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2022-07-20T15:11:51Z
Lists: pgsql-hackers
Attachments
- pldebugger-shmem.patch (text/x-diff) patch
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > On 2022-Jul-20, Tom Lane wrote: >> I'll try to do some research later today to identify anything else >> we need to mark in plpgsql. I recall doing some work specifically >> creating functions for pldebugger's use, but I'll need to dig. > I suppose you're probably thinking of commit 53ef6c40f1e7; that didn't > expose functions directly, but through plpgsql_plugin_ptr. Maybe that > one does need to be made PGDLLEXPORT, since currently it isn't. After some experimentation, it does not need to be marked: pldebugger gets at that via find_rendezvous_variable(), so there is no need for any explicit linkage at all between plpgsql.so and plugin_debugger.so. Along the way, I made a quick hack to get pldebugger to load into v15/HEAD. It lacks #ifdef's which'd be needed so that it'd still compile against older branches, but perhaps this'll save someone some time. regards, tom lane
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