Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Feb 10, 2011 at 1:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> requires, relocatable and schema: These are problematic, because it's not
>> out of the question that someone might want to change these properties
>> from one version to another. �But as things are currently set up, we must
>> know these things before we start to run the extension script, because
>> they are needed to set up the search_path correctly.
> My biggest concern with this extensions work is that these variables
> are poorly designed.
Yeah, I didn't especially like relocatable/schema either. I thought for
awhile about redefining relocatable as a three-way switch, corresponding
to the three use cases (relocatable after the fact, relocatable only at
initial install, no relocation) but didn't pull the trigger. It is
advantageous to have an explicit notion of a particular schema
containing the extension's exported stuff, so that we can add that
schema into the search path for dependent extensions. That means that
you can't easily remove the explicit schema value for the third case,
so it's not that easy to make it look cleaner.
> The extension mechanism is basically the
> equivalent of RPM for inside the database. And while in theory there
> is such a thing as a relocatable RPM, I don't know that I've ever used
> it, at least not successfully.
General opinion around Red Hat is relocatable RPMs don't work. But
pushing a set of functions from one schema to another is a very much
narrower problem than what an RPM has to deal with, so I'm not convinced
that the analogy holds.
Now, if you want to argue that moving an extension after the fact (ALTER
EXTENSION SET SCHEMA) is so dangerous as to be useless, I wouldn't
argue very hard. Do you want to propose ripping that out? But
relocating at first install doesn't seem horrible.
regards, tom lane