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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: pgsql: Default to hidden visibility for extension libraries where possi
Дата
Msg-id 20220719154004.q56qzla6hmxcvh7u@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: pgsql: Default to hidden visibility for extension libraries where possi  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Hi,

On 2022-07-19 17:37:11 +0200, Pavel Stehule wrote:
> út 19. 7. 2022 v 17:31 odesílatel Andres Freund <andres@anarazel.de> napsal:
> 
> > Hi,
> >
> > On 2022-07-19 16:28:07 +0200, Alvaro Herrera wrote:
> > > 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.
> >
> > It does seem a bit random. But I think we probably should err on the side
> > of
> > adding more declarations, rather than the oposite.
> >
> 
> This list can be extended. I think plpgsql_check is maybe one extension
> that uses code from another extension directly. This is really not common
> usage.

There's a few more use cases, e.g. transform modules. Hence exposing e.g. many
plpython helpers.


> I have not any problem with it or with exports.txt file.

Just to be clear, there shouldn't be any use exports.txt here, just a few
PGDLLEXPORTs.

Greetings,

Andres Freund



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: pgsql: Default to hidden visibility for extension libraries where possi
Следующее
От: Rafael Thofehrn Castro
Дата:
Сообщение: Autovacuum worker spawning strategy