From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Regina Obe" <lr(at)pcorp(dot)us> |
Cc: | "'Gregory Stark \(as CFM\)'" <stark(dot)cfm(at)gmail(dot)com>, "'Sandro Santilli'" <strk(at)kbt(dot)io>, pgsql-hackers(at)lists(dot)postgresql(dot)org, "'Regina Obe'" <r(at)pcorp(dot)us> |
Subject: | Re: Ability to reference other extensions by schema in extension scripts |
Date: | 2023-03-10 22:47:17 |
Message-ID: | 1019515.1678488437@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Regina Obe" <lr(at)pcorp(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-03-10 22:49:54 | Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken |
Previous Message | Runqi Tian | 2023-03-10 22:41:44 | Re: Support logical replication of DDLs |