Re: pgsql: Default to hidden visibility for extension libraries where possi

Hi

út 19. 7. 2022 v 16:28 odesílatel Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
napsal:

> [ Redirecting thread to -hackers from -committers ]
>
> On 2022-Jul-19, Tom Lane wrote:
>
> > Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.
>
>
I can confirm that the attached patch fixes plpgsql_check.

Thank you

Pavel

>
> ... 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/
>