Re: pgsql: Default to hidden visibility for extension libraries where possi
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-07-19T15:40:04Z
Lists: 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
Commits
-
Add PGDLLEXPORTS to some plpgsql function declarations
- 1caf915ff31e 16.0 landed
-
Default to hidden visibility for extension libraries where possible
- 089480c07705 16.0 cited
-
Expose a few more PL/pgSQL functions to debugger plugins.
- 53ef6c40f1e7 15.0 cited