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

From Dimitri Fontaine
Subject Re: Extensions vs PGXS' MODULE_PATHNAME handling
Date
Msg-id m2wrl3u92i.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Extensions vs PGXS' MODULE_PATHNAME handling  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Extensions vs PGXS' MODULE_PATHNAME handling  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Or are you suggesting substituting for MODULE_PATHNAME during CREATE
> EXTENSION, and not during "make" at all?  That would work I guess.

That's my idea, sorry not having made it clear enough.  We have $libdir
which is expanded server-side AFAIUI, I though we would have $shlib
expanded the same way and taken from some backend variable like with
creating_extension.

> I'm hesitant to have any substitutions that happen unconditionally,
> but we could add a control parameter like
>     module_pathname = '$libdir/hstore'
> and then things would be pretty clean.

Ok.  Maybe the simpler would be to make the current control variable a
static backend variable so that EXT_CONTROL(module_pathname) is easy to
find out from anywhere (I see you got rid of some direct usage of static
variables with recordDependencyOnCurrentExtension() already).

> 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.

Great!

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: odd output of pg_basebackup
Next
From: Steve Singer
Date:
Subject: Re: pl/python custom exceptions for SPI