RE: Ability to reference other extensions by schema in extension scripts - Mailing list pgsql-hackers

From Regina Obe
Subject RE: Ability to reference other extensions by schema in extension scripts
Date
Msg-id 005501d953a0$906c4df0$b144e9d0$@pcorp.us
Whole thread Raw
In response to Re: Ability to reference other extensions by schema in extension scripts  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Ability to reference other extensions by schema in extension scripts  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> No, pg_depend is not the thing to use for this.  I was thinking of a new
field in
> the extension's control file, right beside where it says it's dependent on
such-
> and-such extensions in the first place.  Say like
> 
>     requires = 'extfoo, extbar'
>     no_relocate = 'extfoo'
> 

So when no_relocate is specified, where would that live?

Would I mark the extfoo as not relocatable on CREATE / ALTER of said
extension?
Or add an extra field to pg_extension

I had tried to do that originally, e.g. instead of even bothering with such
an extra arg, just mark it as not relocatable if the extension's script
contains references to the required extension's schema.

But then what if extfoo is upgraded?

ALTER EXTENSION extfoo UPDATE;

Wipes out the not relocatable of extfoo set. 
So in order to prevent that, I have to 

a) check the control files of all extensions that depend on foo to see if
they made such a request.
or 
b) "Seeing if the extension is marked as not relocatable, prevent ALTER
EXTENSION from marking it as relocatable"
problem with b is what if the extension author changed their mind and wanted
it to be relocatable? Given the default is (not relocatable), it's possible
the author didn't know this and later decided to put in an explicit
relocate=false.
c) define a new column in pg_extension to hold this bit of info.  I was
hoping I could reuse pg_extension.extconfig, but it seems that's hardwired
to be only used for backup.

Am I missing something or is this really as complicated as I think it is?

If we go with b) I'm not sure why I need to bother defining a no_relocate,
as it's obvious looking at the extension install/upgrade script that it
should not be relocatable.

> > So you are proposing I change the execute_extension_scripts input args
> > to take more args?
> 
> Why not?  It's local to that file, so you won't break anything.
> 

Okay, I wasn't absolutely sure if it was.  If it is then I'll change.

>             regards, tom lane


Thanks,
Regina




pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: [PoC] Let libpq reject unexpected authentication requests
Next
From: Thomas Munro
Date:
Subject: Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken