From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Andrew Gierth <andrew@tao11.riddles.org.uk>,
        Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <pg@bowt.ie>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Should contrib modules install .h files?
In-reply-to: <20180802182144.6qrkfct47u3s2w7t@alap3.anarazel.de>
References: <87o9enb4h7.fsf@news-spur.riddles.org.uk>
 <20180731201700.zfscje7clxiljvjl@alap3.anarazel.de>
 <CAH2-Wz=imVrbydSkBH95y3w7ZU7XffE7-LW0R+LjfZrXnyz-dw@mail.gmail.com>
 <11978.1533073999@sss.pgh.pa.us>
 <CA+TgmoZB9fVOd-8ZSWLaKX_TVAV9y0+7YrUn8vbpAPL_4XmGPw@mail.gmail.com>
 <1836.1533221640@sss.pgh.pa.us> <87lg9oaghh.fsf@news-spur.riddles.org.uk>
 <25706.1533229991@sss.pgh.pa.us> <87a7q4adnk.fsf@news-spur.riddles.org.uk>
 <87600sabb2.fsf@news-spur.riddles.org.uk>
 <20180802182144.6qrkfct47u3s2w7t@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Thu, 02 Aug 2018 11:21:44 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <31577.1533234698.1@sss.pgh.pa.us>
Date: Thu, 02 Aug 2018 14:31:38 -0400
Message-ID: <31578.1533234698@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2018-08-02 19:13:05 +0100, Andrew Gierth wrote:
>> And none of the plpython transforms can even parse their makefiles with
>> USE_PGXS, let alone build, because they have an "include" directive
>> pointing into src/pl/plpython.

> FWIW, I'd be perfectly on board with just burying this policy. Designating
> one contrib module (or something in src/test/examples or such) as a PGXS
> example, and always building it with pgxs seems like it'd do a much
> better job than the current policy.

No, I think that'd be pretty wrongheaded.  One of the big reasons for
contrib to exist is to serve as a testbed proving that our extension
features actually work.  What you suggest would reduce the scope of
that testing, which seems like the wrong direction to be going in.

It's particularly bad for these cases, since what they demonstrate is
that it's impossible to build transform modules for plperl or plpython
out-of-tree at the moment.  That doesn't seem to me to be something
we should just ignore; it goes against not only our larger commitment
to extensibility, but also the entire point of the transforms feature.

			regards, tom lane