Re: Extensions vs PGXS' MODULE_PATHNAME handling - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Extensions vs PGXS' MODULE_PATHNAME handling
Date
Msg-id 17109.1297614501@sss.pgh.pa.us
Whole thread Raw
In response to Re: Extensions vs PGXS' MODULE_PATHNAME handling  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Extensions vs PGXS' MODULE_PATHNAME handling  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> But contrib/spi is exactly the case where it *won't* work.  We need to
>> somehow figure out that $libdir/autoinc is what to substitute in
>> autoinc-1.0.sql, $libdir/insert_username in insert_username-1.0.sql,
>> etc.

> Indeed.  That's why I'm proposing to have that setup in the control
> file, which is per extension, rather than in the common Makefile.

How's that help?  In a makefile building more than one extension,
you'd still need a way to decide which extension the current script
file is associated with.

Or are you suggesting substituting for MODULE_PATHNAME during CREATE
EXTENSION, and not during "make" at all?  That would work I guess.
I'm hesitant to have any substitutions that happen unconditionally,
but we could add a control parameter likemodule_pathname = '$libdir/hstore'
and then things would be pretty clean.

I think we should still change the file naming conventions to use double
dashes, though, since there's more than one reason to want that.  Will
work on that next.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Add support for logging the current role
Next
From: Michael Banck
Date:
Subject: Re: Debian readline/libedit breakage