Re: Ability to reference other extensions by schema in extension scripts

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Regina Obe" <lr@pcorp.us>
Cc: "'Sandro Santilli'" <strk@kbt.io>, "'Gregory Stark \(as CFM\)'" <stark.cfm@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-03-21T14:52:11Z
Lists: pgsql-hackers
"Regina Obe" <lr@pcorp.us> writes:
>> making the no_relocate values visible somehow, I'm not convinced that
>> pg_available_extension_versions should be the place to do it.  ISTM what's
>> relevant is the no_relocate values of *installed* extensions, not those of
>> potentially-installable extensions.  If we had a view over pg_extension then
>> that might be a place to add this, but we don't.  On the whole it didn't seem
>> important enough to pursue, so I just left it out.

> Thanks.  Agree with get_available_versions_for_extension, not necessary.

If we did feel like doing something about this, on reflection I think
the thing to do would be to add no_relocate as an actual column in
pg_extension, probably of type "oid[]".  Then we could modify the
SET SCHEMA code to check that instead of parsing the extension control
files.  That'd be a little cleaner, but I can't say that I'm hugely
excited about it.

			regards, tom lane



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add @extschema:name@ and no_relocate options to extensions.

  2. pkg-config Requires.private entries should be comma-separated

  3. Fix logic buglets in pg_dump's flagInhAttrs().