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 001d01d953f2$099b6430$1cd22c90$@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  ('Sandro Santilli' <strk@kbt.io>)
List pgsql-hackers
> Subject: Re: Ability to reference other extensions by schema in extension
> scripts
> 
> "Regina Obe" <lr@pcorp.us> writes:
> >> requires = 'extfoo, extbar'
> >> no_relocate = 'extfoo'
> 
> > So when no_relocate is specified, where would that live?
> 
> In the control file.
> 
> > Would I mark the extfoo as not relocatable on CREATE / ALTER of said
> > extension?
> > Or add an extra field to pg_extension
> 
> We don't record dependent extensions in pg_extension now, so that doesn't
> seem like it would fit well.  I was envisioning that ALTER EXTENSION SET
> SCHEMA would do something along the lines of
> 
> (1) scrape the list of dependent extensions out of pg_depend
> (2) open and parse each of their control files
> (3) fail if any of their control files mentions the target one in
>     no_relocate.
> 
> Admittedly, this'd be a bit slow, but I doubt that ALTER EXTENSION SET
> SCHEMA is a performance bottleneck for anybody.
> 
> > 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.
> 
> I don't think that's a great approach, because those references might
appear
> in places that can track a rename (ie, in an object name that's resolved
to a
> stored OID).  Short of fully parsing the script file you aren't going to
get a
> reliable answer.  I'm content to lay that problem off on the extension
authors.
> 
> > But then what if extfoo is upgraded?
> 
> We already have mechanisms for version-dependent control files, so I don't
> see where there's a problem.
> 
>             regards, tom lane

Attached is a revised patch with these changes in place.

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher
Next
From: Ankit Kumar Pandey
Date:
Subject: Re: optimize several list functions with SIMD intrinsics