Re: extensions are hitting the ceiling
От | Noah Misch |
---|---|
Тема | Re: extensions are hitting the ceiling |
Дата | |
Msg-id | 20190416054721.GB2362100@rfd.leadboat.com обсуждение исходный текст |
Ответ на | extensions are hitting the ceiling (Eric Hanson <eric@aquameta.com>) |
Ответы |
Re: extensions are hitting the ceiling
(Eric Hanson <eric@aquameta.com>)
|
Список | pgsql-hackers |
On Mon, Mar 18, 2019 at 09:38:19PM -0500, Eric Hanson wrote: > #1: Dependencies > > Let's say we have two extensions, A and B, both of which depend on a third > extension C, let's just say C is hstore. A and B are written by different > developers, and both contain in their .control file the line > > requires = 'hstore' > > When A is installed, if A creates a schema, it puts hstore in that schema. > If not, hstore is already installed, it uses it in that location. How does > the extension know where to reference hstore? > > Then, when B is installed, it checks to see if extension hstore is > installed, sees that it is, and moves on. What if it expects it in a > different place than A does? The hstore extension can only be installed > once, in a single schema, but if multiple extensions depend on it and look > for it in different places, they are incompatible. > > I have heard talk of a way to write extensions so that they dynamically > reference the schema of their dependencies, but sure don't know how that > would work if it's possible. The @extschema@ variable references the > *current* extension's schema, but not there is no dynamic variable to > reference the schema of a dependency. If desperate, you can do it like this: DO $$ BEGIN EXECUTE format('SELECT %I.earth()', (SELECT nspname FROM pg_namespace n JOIN pg_extension ON n.oid = extnamespace WHERE extname = 'earthdistance' )); END $$; Needless to say, that's too ugly. Though probably unimportant in practice, it also has a race condition vs. ALTER EXTENSION SET SCHEMA. > Also it is possible in theory to dynamically set search_path to contain > every schema of every dependency in play and then just not specify a schema > when you use something in a dependency. But this ANDs together all the > scopes of all the dependencies of an extension, introducing potential for > collisions, and is generally kind of clunky. That's how it works today, and it has the problems you describe. I discussed some solution candidates here: https://www.postgresql.org/message-id/20180710014308.GA805781@rfd.leadboat.com The @DEPNAME_schema@ thing was trivial to implement, but I shelved it. I'm attaching the proof of concept, for your information. > #2: Data in Extensions > > Extensions that are just a collection of functions and types seem to be the > norm. Extensions can contain what the docs call "configuration" data, but > rows are really second class citizens: They aren't tracked with > pg_catalog.pg_depend, they aren't deleted when the extension is dropped, > etc. > > Sometimes it would make sense for an extension to contain *only* data, or > insert some rows in a table that the extension doesn't "own", but has as a > dependency. For example, a "webserver" extension might contain a > "resource" table that serves up the content of resources in the table at a > specified path. But then, another extension, say an app, might want to just > list the webserver extension as a dependency, and insert a few resource > rows into it. This is really from what I can tell beyond the scope of what > extensions are capable of. I never thought of this use case. Interesting.
Вложения
В списке pgsql-hackers по дате отправления: