Re: regress bug - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: regress bug
Date
Msg-id BFE91752-7931-4058-9241-549F51F870F1@justatheory.com
Whole thread Raw
In response to Re: regress bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: regress bug
List pgsql-hackers
On Mar 8, 2012, at 12:59 PM, Tom Lane wrote:

> Huh?  MODULE_PATHNAME is not substituted by pg_regress at all (anymore
> anyway).

Yeah, sorry, I meant `make`.

> There's still some vestigial support for it in pgxs.mk, but
> the future of that code is to vanish, not get improved.  You should
> not be needing it to get substituted at build time either.

I still see this pattern a *lot*; I removed it from PL/Proxy last week. The attached tarball demonstrates it:

    > make
    sed 's,MODULE_PATHNAME,$libdir/sql/exttest,g' sql/exttest.sql.in >sql/exttest.sql
    make: *** No rule to make target `exttest.so', needed by `all'.  Stop.

So MODULE_PATHNAME is replaced with $libdir/sql/exttest rather than $libdir/exttest. Maybe that should not be fixed,
butthere are a *lot* of extensions out there using this approach (copied from contrib, which used it for years, albeit
withoutthe .sql.in files in a subdirectory). 

So perhaps DATA_built is to be removed from pgxs.mk? And if so, is the idea then that one should just put the module
namein the .sql file, rather than MODULE_PATHNAME in a .sql.in file? 

Best,

David

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Optimize IS DISTINCT FROM NULL => IS NOT NULL
Next
From: Peter Eisentraut
Date:
Subject: Re: pg_upgrade --logfile option documentation