From: | Sandro Santilli <strk(at)kbt(dot)io> |
---|---|
To: | 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 |
Date: | 2023-01-18 21:42:23 |
Message-ID: | 20230118214223.2crj7hh3i5amzkji@c19 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 16, 2023 at 11:57:30PM -0500, Regina Obe wrote:
> What would be more bullet-proof is having an extra column in pg_extension or
> adding an extra array element to pg_extension.extcondition[] that allows you
> to say "Hey, don't allow this to be relocatable cause other extensions
> depend on it that have explicitly referenced the schema."
I've given this some more thoughts and I think a good
compromise could be to add the safety net in ALTER EXTESION SET SCHEMA
so that it does not only check "extrelocatable" but also the presence
of any extension effectively depending on it, in which case the
operation could be prevented with a more useful message than
"extension does not support SET SCHEMA" (what is currently output).
Example query to determine those cases:
SELECT e.extname, array_agg(v.name)
FROM pg_extension e, pg_available_extension_versions v
WHERE e.extname = ANY( v.requires )
AND e.extrelocatable
AND v.installed group by e.extname;
extname | array_agg
---------------+--------------------------
fuzzystrmatch | {postgis_tiger_geocoder}
--strk;
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-01-18 21:42:40 | Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation |
Previous Message | Bruce Momjian | 2023-01-18 21:23:41 | Re: document the need to analyze partitioned tables |