public inbox for [email protected]
help / color / mirror / Atom feedFrom: Regina Obe <[email protected]>
To: 'Tom Lane' <[email protected]>
Cc: 'Gregory Stark (as CFM)' <[email protected]>
Cc: 'Sandro Santilli' <[email protected]>
Cc: [email protected]
Cc: 'Regina Obe' <[email protected]>
Subject: RE: Ability to reference other extensions by schema in extension scripts
Date: Fri, 10 Mar 2023 17:35:05 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<167762779361.628976.14009177203307564086.pgcf@coridan.postgresql.org>
<CAM-w4HP91M-r=h4nExwonHf03SRwKyNYnvFHX2FFoFMv0pRQBA@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
> 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
view thread (14+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: RE: Ability to reference other extensions by schema in extension scripts
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox