RE: Ability to reference other extensions by schema in extension scripts

From: "Regina Obe" <lr(at)pcorp(dot)us>
To: <strk(at)kbt(dot)io>
Cc: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Ability to reference other extensions by schema in extension scripts
Date: 2023-02-26 06:39:24
Message-ID: 000001d949ad$1159adc0$340d0940$
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> So in conclusion we have 3 possible paths to go with this
> 1) Just don't allow any extensions referenced by other extensions to be
> relocatable.
> It will show a message something like
> "SET SCHEMA not allowed because other extensions depend on it"
> Given that if you don't specify relocatable in you .control file, the
assume is
> relocatable = false , this isn't too far off from standard protocol.
> 2) Use objsubid=1 to denote that another extension explicitly references
> schema of another extension so setting schema of other extension is not
> So instead of introducing another dependency, we'd update the
> DEPENDENCY_NORMAL one between the two schemas with objsubid=1
> instead of 0.
> This has 2 approaches:
> a) Update the existing DEPENDENCY_NORMAL between the two extensions
> setting the objsubid=1
> or
> b) Create a new DEPEDENCY_NORMAL between the two extensions with
> objsubid=1
> I'm not sure if either has implications in backup / restore . I suspect b
> be safer since I suspect objsubid might be checked and this dependency
> needs checking during SET SCHEMA time.
> 3) Create a whole new DEPENDENCY type, perhaps calling it something like
> 4) Just don't allow @extschema:<reqextension>@ syntax to be used unless
> the <reqextension> is marked as relocatable=false. This one I don't like
> because it doesn't solve my fundamental issue of
> postgis_tiger_geocoder relying on fuzzystrmatch, which is marked as
> relocatable.
> The main issue I was trying to solve is my extension references
> functions in a function used for functional indexes, and this fails
restore of
> table indexes because I can't schema qualify the fuzzystrmatch extension
> the backing function.
> If no one has any opinion, I'll go with option 1 which is the one that
strk had
> actually proposed before and seems least programmatically invasive, but
> perhaps more annoying user facing.
> My preferred would be #2
> Thanks,
> Regina

Attached is my revision 3 patch, which follows the proposed #1.
Don't allow schema relocation of an extension if another extension requires

Attachment Content-Type Size
0003-Allow-use-of-extschema-reqextname-to-reference.patch application/octet-stream 15.2 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2023-02-26 09:11:47 Re: Doc updates for MERGE
Previous Message Michael Paquier 2023-02-26 05:35:22 Re: verbose mode for pg_input_error_message?