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

From Robert Haas
Subject Re: [PATCH] postgres_fdw extension support
Date
Msg-id CA+TgmoaZwLtThe_=v6HFjoxBqh+gSa9ApDUatzG54K0mpn=3xg@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 Tue, Nov 3, 2015 at 2:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Paul Ramsey <pramsey@cleverelephant.ca> writes:
>> [ 20151006b_postgres_fdw_extensions.patch ]
>
> Starting to look through this now.  I'm dubious of the decision to have
> ExtractExtensionList throw errors if there are un-installed extensions
> mentioned in the FDW options.  Wouldn't it be a lot more convenient if
> such extension names were silently ignored?  You cannot guarantee that the
> list is always up to date anyway; consider creating a server, setting some
> extension options, and then dropping some of those extensions.  Moreover,
> the current semantics create a hazard for pg_dump, which can't reasonably
> be expected to know that it must restore extensions X and Y before it can
> create foreign server Z.
>
> There might be a case for raising a WARNING during
> postgres_fdw_validator(), but no more than that, IMO.  Certainly ERROR
> during regular use of the server is right out.

Agreed.  I don't know whether it's better to emit a WARNING or some
lower-level message (INFO, DEBUG), but I think an ERROR will suck due
to the pg_dump issues you mention.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] postgres_fdw extension support
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: PL/Pythonu - function ereport