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: 2023-02-28T22:13:55Z
Lists: pgsql-hackers
On Sat, Feb 25, 2023 at 03:40:24PM -0500, Regina Obe wrote: > > On Mon, Feb 06, 2023 at 05:19:39AM -0500, Regina Obe wrote: > > > > I was thinking: how about using the "refobjsubid" to encode the "level" of > > dependency on an extension ? Right now "refobjsubid" is always 0 when the > > referenced object is an extension. > > Could we consider subid=1 to mean the dependency is not only on the > > extension but ALSO on it's schema location ? > > I like that idea. It's only been ever used for tables I think, but I don't > see why it wouldn't apply in this case as the concept is kinda the same. > Only concern if other parts rely on this being 0. This has to be verified, yes. But it feels to me like "must be 0" was mostly to _allow_ for future extensions like the proposed one. > The other question, should this just update the existing DEPENDENCY_NORMAL > extension or add a new DEPENDENCY_NORMAL between the extensions with > subid=1? I'd use the existing record. --strk; Libre GIS consultant/developer https://strk.kbt.io/services.html
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