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

Поиск
Список
Период
Сортировка
От Regina Obe
Тема RE: Ability to reference other extensions by schema in extension scripts
Дата
Msg-id 000001d949ad$1159adc0$340d0940$@pcorp.us
обсуждение исходный текст
Ответ на Ability to reference other extensions by schema in extension scripts  ("Regina Obe" <lr@pcorp.us>)
Ответы Re: Ability to reference other extensions by schema in extension scripts
Список 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
the
> schema of another extension so setting schema of other extension is not
okay.
> 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
would
> be safer since I  suspect objsubid might be checked and this dependency
only
> needs checking during SET SCHEMA time.
> 
> 3) Create a whole new DEPENDENCY type, perhaps calling it something like
> DEPENDENCY_EXTENSION_SCHEMA
> 
> 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
fuzzystrmatch
> functions in  a function used for functional indexes, and this fails
restore of
> table indexes because I can't schema qualify the fuzzystrmatch extension
in
> 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
it.


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: verbose mode for pg_input_error_message?
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: Doc updates for MERGE