> On Tue, Nov 22, 2022 at 11:24:19PM -0500, Regina Obe wrote: > > > Here is first version of my patch using the @extschema:extensionname@ > > syntax you proposed. > > > > This patch includes: > > 1) Changes to replace references of @extschema:extensionname@ with the > > schema of the required extension > > 2) Documentation for the feature > > 3) Tests for the feature. > > > > There is one issue I thought about that is not addressed by this. > > > > If an extension is required by another extension and that required > > extension schema is referenced in the extension scripts using the > > @extschema:extensionname@ syntax, then ideally we should prevent the > > required extension from being relocatable. This would prevent a user > > from accidentally moving the required extension, thus breaking the > > dependent extensions. > > > > I didn't add that feature cause I wasn't sure if it was overstepping > > the bounds of what should be done, or if we leave it up to the user to > > just know better. > > An alternative would be to forbid using @extschema:extensionname@ to > reference relocatable extensions. DBA can toggle relocatability of an extension > to allow it to be referenced. > > --strk; That would be hard to do in a DbaaS setup and not many users know they can fiddle with extension control files. Plus those would get overwritten with upgrades.
In my case for example I have postgis_tiger_geocoder that relies on both postgis and fuzzystrmatch. I'd rather not have to explain to users how to fiddle with the fuzzystrmatch.control file to make it not relocatable. But I don't think anyone would mind if it's forced after install because it's a rare thing for people to be moving extensions to different schemas after install. Thanks, Regina
