Re: [PATCH] postgres_fdw extension support - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [PATCH] postgres_fdw extension support
Date
Msg-id CAB7nPqRqAwWy7OuMXa+_sJZuvNf7OZpqJgyyPqoLOPq=khoGww@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] postgres_fdw extension support  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] postgres_fdw extension support  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Nov 4, 2015 at 12:38 PM, Tom Lane wrote:
> I wrote:
>> I left out the proposed regression tests because they fail in "make
>> installcheck" mode, unless you've previously built and installed cube
>> and seg, which seems like an unacceptable requirement to me.  I don't
>> think that leaving the code untested is a good final answer, of course.
>> The idea I was toying with was to create a dummy extension for testing
>> purposes by means of doing a direct INSERT into pg_extension --- which
>> is ugly and would only work for superusers, but the latter is true of
>> "CREATE EXTENSION cube" too.  Anybody have a better idea?
>
> I had a possibly better idea: instead of manufacturing an empty extension
> with a direct INSERT, hack on the one extension that we know for sure
> will be installed, namely postgres_fdw itself.  So we could do, eg,
>
> create function foo() ...
> alter extension postgres_fdw add function foo();
> and then test shippability of foo() with or without having listed
> postgres_fdw as a shippable extension.

Yeah, I don't have a better idea than that. Could we consider shipping
that in a different library than postgres_fdw.so, like
postgres_fdw_test.so? That's still strange to have a dummy object in
postgres_fdw.so just for testing purposes.
-- 
Michael



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: RFC/WIP: adding new configuration options to TOAST
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] postgres_fdw extension support