Tom Lane <tgl@sss.pgh.pa.us> writes:
>>> In general, we would now have a situation where relocatable extensions
>>> could never be installed into pg_catalog. That might be OK, but at
>>> least it would need to be documented.
I've been idly trying to think of examples where that would be a
problem, without success.
Other than adminpack, I know of PGQ installing their objects in
pg_catalog. They only began doing that when switching to the CREATE
EXTENSION facility. And they set relocatable to false.
> Given the lack of any good alternative proposals, I think we should
> press ahead with this approach. We still need doc updates and fixes
I would have to re-read the whole thread and pay close attention, but I
remember having that gut feeling you have when you don't like the design
and are not able to put words on why.
Now, any idea to clean that up is bound to be a nightmare to design
properly. I still remember being burnt hard when trying to work on
extensions and seach_path…
> for the affected contrib module(s), though. Also, in view of point 2,
> it seems like the extensions code should test for and reject an attempt
> to set a relocatable extension's schema to pg_catalog. Otherwise you'd
> be likely to get not-too-intelligible errors from the extension script.
Reading the code now, it seems to me that we lack a more general test
and error situation to match with the comments.
else if (control->schema != NULL){ /* * The extension is not relocatable and the author gave us a schema *
forit. We create the schema here if it does not already exist. */
We should probably error out when entering in that block of code if the
extension is relocatable at all, right? That would fix the pg_catalog
case as well as the general one.
I should be able to prepare a patch early next week to fix that if
you're not done by then…
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
