Re: Ability to reference other extensions by schema in extension scripts
Sandro Santilli <strk@kbt.io>
From: Sandro Santilli <strk@kbt.io>
To: Regina Obe <lr@pcorp.us>
Cc: 'Tom Lane' <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2022-12-15T08:52:34Z
Lists: pgsql-hackers
On Tue, Nov 22, 2022 at 11:24:19PM -0500, Regina Obe wrote: > Here is first version of my patch using the @extschema:extensionname@ syntax > you proposed. > > This patch includes: > 1) Changes to replace references of @extschema:extensionname@ with the > schema of the required extension > 2) Documentation for the feature > 3) Tests for the feature. > > There is one issue I thought about that is not addressed by this. > > If an extension is required by another extension and that required extension > schema is referenced in the extension scripts using the > @extschema:extensionname@ syntax, then ideally we should prevent the > required extension from being relocatable. This would prevent a user from > accidentally moving the required extension, thus breaking the dependent > extensions. > > I didn't add that feature cause I wasn't sure if it was overstepping the > bounds of what should be done, or if we leave it up to the user to just know > better. An alternative would be to forbid using @extschema:extensionname@ to reference relocatable extensions. DBA can toggle relocatability of an extension to allow it to be referenced. --strk;
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add @extschema:name@ and no_relocate options to extensions.
- 72a5b1fc8804 16.0 landed
-
pkg-config Requires.private entries should be comma-separated
- 4ef1be5a0b67 16.0 cited
-
Fix logic buglets in pg_dump's flagInhAttrs().
- 128dd9f9eca0 16.0 cited