|From:||"Regina Obe" <lr(at)pcorp(dot)us>|
|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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
> 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
> 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
> b) Create a new DEPEDENCY_NORMAL between the two extensions with
> 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
> The main issue I was trying to solve is my extension references
> functions in a function used for functional indexes, and this fails
> 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
> actually proposed before and seems least programmatically invasive, but
> perhaps more annoying user facing.
> My preferred would be #2
Attached is my revision 3 patch, which follows the proposed #1.
Don't allow schema relocation of an extension if another extension requires
|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?|