Re: pgsql: Default to hidden visibility for extension libraries where possi
От | Dave Page |
---|---|
Тема | Re: pgsql: Default to hidden visibility for extension libraries where possi |
Дата | |
Msg-id | CA+OCxowCKpKfLa8W8rOXUeeO4kZ++Swb6kx44XtBR+ePTJgQ2w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Default to hidden visibility for extension libraries where possi (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, 20 Jul 2022 at 16:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.
Thanks Tom - I've pushed that patch with the relevant #ifdefs added.
В списке pgsql-hackers по дате отправления: