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

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: pgsql: Default to hidden visibility for extension libraries where possi
Дата
Msg-id CAFj8pRCz3nSQMFUdX5sdoPdR12JWDif8kBGbcGOrii_+-nbb5w@mail.gmail.com
обсуждение исходный текст
Список pgsql-hackers
Hi

út 19. 7. 2022 v 16:28 odesílatel Alvaro Herrera <alvherre@alvh.no-ip.org> napsal:
[ 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.


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/

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: pgsql: Default to hidden visibility for extension libraries where possi
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Costing elided SubqueryScans more nearly correctly