From: Tom Lane <tgl@sss.pgh.pa.us>
To: Sandro Santilli <strk@kbt.io>
cc: Regina Obe <lr@pcorp.us>, "'Gregory Stark (as CFM)'" <stark.cfm@gmail.com>,
        pgsql-hackers@lists.postgresql.org, "'Regina Obe'" <r@pcorp.us>
Subject: Re: Ability to reference other extensions by schema in extension scripts
In-reply-to: <20230316101418.2a32erangr3nvnuk@c19>
References: <CAM-w4HP91M-r=h4nExwonHf03SRwKyNYnvFHX2FFoFMv0pRQBA@mail.gmail.com> <005401d95083$26ca24a0$745e6de0$@pcorp.us> <995823.1678478825@sss.pgh.pa.us> <004b01d95394$16123ee0$4236bca0$@pcorp.us> <1012975.1678486476@sss.pgh.pa.us> <005501d953a0$906c4df0$b144e9d0$@pcorp.us> <1019515.1678488437@sss.pgh.pa.us> <001d01d953f2$099b6430$1cd22c90$@pcorp.us> <20230313115916.ivvg4tj54szeu5rj@c19> <000701d955f6$dfaaf8a0$9f00e9e0$@pcorp.us> <20230316101418.2a32erangr3nvnuk@c19>
Comments: In-reply-to Sandro Santilli <strk@kbt.io>
	message dated "Thu, 16 Mar 2023 11:14:18 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1103861.1679352440.1@sss.pgh.pa.us>
Date: Mon, 20 Mar 2023 18:47:20 -0400
Message-ID: <1103862.1679352440@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1103862.1679352440%40sss.pgh.pa.us>
Precedence: bulk

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