Re: ALTER EXTENSION UPGRADE, v3

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On Feb 11, 2011, at 10:30 AM, Tom Lane wrote:
>> It can be specified by a "directory" parameter in the control file,
>> and defaults to the same place the control file is. Right now, that's
>> $PREFIX/share/contrib/.

> Frankly, given the likely proliferation of upgrade scripts, I think it ought to be $PREFIX/share/contrib/$extension/

I think it should be up to the extension author to decide to do that,
just as it is now. However I do see a bug in the current PGXS coding:
if MODULEDIR is set, that should affect DATA and DOCS files but *not*
the primary extension control file, because the place where that must
be is hard-wired into extension.c. MODULEDIR should just affect the
files whose location will be determined by the directory parameter in
the control file. Then, if an extension author wants to put his stuff
in his own subdirectory, he sets something like

MODULEDIR = extension/hstore

in the makefile and

directory = hstore

in the control file.

>> One other thing that ought to be discussed is
>> whether to stick with that choice or change it. Given that some people
>> have great antipathy to the word "contrib", I suspect there will be
>> argument to change it --- but to do so, I think we'd have to change the
>> default MODULEDIR in PGXS, and I'm not sure that's a good idea.

> Add EXTENSIONDIR and make it "extensions".

Well, it's not exactly that easy, because we don't want to break the
file layout that an old-style module is expecting PGXS to produce.
But I guess what we could do is make the default definition of MODULEDIR
depend on whether or not EXTENSION has been defined: "extension" if so,
and backwards-compatible "contrib" if not.

BTW, I'm inclined to make it $PREFIX/share/extension not extensions,
but I have to admit I'm hard-pressed to explain exactly why that feels
better. Anybody else care about that detail?

regards, tom lane