> 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)
