Re: Ability to reference other extensions by schema in extension scripts - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Ability to reference other extensions by schema in extension scripts
Date
Msg-id 1103862.1679352440@sss.pgh.pa.us
Whole thread Raw
In response to Re: Ability to reference other extensions by schema in extension scripts  (Sandro Santilli <strk@kbt.io>)
Responses RE: Ability to reference other extensions by schema in extension scripts  ("Regina Obe" <lr@pcorp.us>)
List pgsql-hackers
Sandro Santilli <strk@kbt.io> writes:
> On Mon, Mar 13, 2023 at 05:57:57PM -0400, Regina Obe wrote:
>> Attached is a slightly revised patch to fix the extra whitespace in the
>> extend.gml document that Sandro noted to me.

> Thanks Regina.
> I've tested attached patch (md5 0b652a8271fc7e71ed5f712ac162a0ef)
> against current master (hash 4ef1be5a0b676a9f030cc2e4837f4b5650ecb069).
> The patch applies cleanly, builds cleanly, regresses cleanly.

Pushed with some mostly-cosmetic adjustments (in particular I tried
to make the docs and tests neater).

I did not commit the changes in get_available_versions_for_extension
to add no_relocate as an output column.  Those were dead code because
you hadn't done anything to connect them up to an actual output parameter
of pg_available_extension_versions().  While I'm not necessarily averse
to 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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Add LZ4 compression in pg_dump
Next
From: Merlin Moncure
Date:
Subject: Re: Request for comment on setting binary format output per session