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

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

  1. Add PGDLLEXPORTS to some plpgsql function declarations

  2. Default to hidden visibility for extension libraries where possible

  3. Expose a few more PL/pgSQL functions to debugger plugins.