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

From Tom Lane
Subject Re: [PATCH] postgres_fdw extension support
Date
Msg-id 11981.1446608335@sss.pgh.pa.us
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  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
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.

This is certainly pretty ugly in its own right, but it would avoid
the maintainability hazards of an explicit INSERT into pg_extension.
So on balance it seems a bit nicer than my first idea.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Amit Kapila
Date:
Subject: Re: ParallelContexts can get confused about which worker is which