On Thu, Dec 15, 2022 at 08:04:22AM -0500, Regina Obe wrote:
> > On Tue, Nov 22, 2022 at 11:24:19PM -0500, Regina Obe wrote:
> >
> > > 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.
>
> 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.
Wouldn't this also be the case if you override relocatability ?
Case:
- Install fuzzystrmatch, marked as relocatable
- Install ext2 depending on the former, which is them marked
non-relocatable
- Upgrade database -> fuzzystrmatch becomes relocatable again
- Change fuzzystrmatch schema BREAKING ext2
Allowing to relocate a dependency of other extensions using the
@extschema@ syntax is very dangerous.
I've seen that PostgreSQL itself doesn't even bother to replace
@extschema@ IF the extension using it doesn't mark itself as
non-relocatable. For consistency this patch should basically refuse
to expand @extschema:fuzzystrmatch@ if "fuzzystrmatch" extension
is relocatable.
Changing the current behaviour of PostgreSQL could be proposed but
I don't think it's to be done in this thread ?
So my suggestion is to start consistent (do not expand if referenced
extension is relocatable).
--strk;
