From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] postgres_fdw extension support |
Date: | 2015-11-04 03:38:55 |
Message-ID: | 11981.1446608335@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2015-11-04 04:07:58 | Re: ParallelContexts can get confused about which worker is which |
Previous Message | Amit Kapila | 2015-11-04 03:19:48 | Re: Freeze avoidance of very large table. |