From: "Regina Obe" <lr@pcorp.us>
To: <strk@kbt.io>
Cc: "'Tom Lane'" <tgl@sss.pgh.pa.us>,
	"'Gregory Stark \(as CFM\)'" <stark.cfm@gmail.com>,
	<pgsql-hackers@lists.postgresql.org>,
	"'Regina Obe'" <r@pcorp.us>
References: <000401d94bc8$48dff700$da9fe500$@pcorp.us> <167762779361.628976.14009177203307564086.pgcf@coridan.postgresql.org> <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>
In-Reply-To: <20230313115916.ivvg4tj54szeu5rj@c19>
Subject: RE: Ability to reference other extensions by schema in extension scripts
Date: Mon, 13 Mar 2023 10:28:04 -0400
Message-ID: <000601d955b8$068456e0$138d04a0$@pcorp.us>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQFb3UkpK58iwMTTldDTs6BRw63MSAJahjgRAXVpL3oC133W8wIdikw1AqkAkisBwBvvuQJrBFYcAhn2WrEDIVE3ogJhu78/rzoAQ/A=
Content-Language: en-us
Archived-At: <https://www.postgresql.org/message-id/000601d955b8%24068456e0%24138d04a0%24%40pcorp.us>
Precedence: bulk

> I've given a try to this patch. It builds and regresses fine.
> 
> My own tests also worked fine. As long as ext1 was found in the ext2's
> no_relocate list it could not be relocated, and proper error message is
given
> to user trying it.
> 
> Nitpicking, there are a few things that are weird to me:
> 
> 1) I don't get any error/warning if I put an arbitrary string into
no_relocate
> (there's no check to verify the no_relocate is a subset of the requires).
> 

I thought about that and decided it wasn't worth checking for.  If an
extension author puts in an extension not in requires it's on them as the
docs say it should be in requires.

It will just pretend that extension is not listed in no_relocate.

> 2) An extension can still reference extensions it depends on without
putting
> them in no_relocate. This may be intentional, as some substitutions may
not
> require blocking relocation, but felt inconsistent with the normal
> @extschema@ which is never replaced unless an extension is marked as non-
> relocatable.
> 
> --strk;
> 
>   Libre GIS consultant/developer
>   https://strk.kbt.io/services.html


Yes this is intentional.  As Tom mentioned, if for example an extension
author decides
To schema qualify @extschema:foo@ in their table definition, and they marked
as requiring foo
since such a reference 
is captured by a schema move, there is no need for them to prevent relocate
of the foo extension (assuming foo was relocatable to begin with)