Re: Missing importing option of postgres_fdw

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Missing importing option of postgres_fdw
Date: 2015-04-30 08:15:46
Message-ID: 5541E4B2.6070500@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015/04/30 2:10, Robert Haas wrote:
> On Mon, Apr 27, 2015 at 7:47 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> Authorizing ALTER FOREIGN TABLE as query string that a FDW can use
>> with IMPORT FOREIGN SCHEMA is a different feature than what is
>> proposed in this patch, aka an option for postgres_fdw and meritates a
>> discussion on its own because it impacts all the FDWs and not only
>> postgres_fdw. Now, related to this patch, we could live without
>> authorizing ALTER FOREIGN TABLE because CREATE FOREIGN TABLE does
>> authorize the definition of CHECK constraints.
>
> I agree. I don't think there's a huge problem with allowing IMPORT
> FOREIGN SCHEMA to return ALTER FOREIGN TABLE statements, but it
> doesn't really seem to be necessary. I don't see why we can't just
> declare the CHECK constraints in the CREATE FOREIGN TABLE statement
> instead of adding more DDL.

I think that it'd improve the convenience of an FDW developer writing
ImportForeignSchema() to allow it to return ALTER FOREIGN TABLE (and
perhaps DROP FOREIGN TABLE) as well, but I agree that that needs another
discussion. So I'll leave that as is and update the patch as discussed
above.

Thanks for the comments!

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2015-04-30 08:24:42 Re: PL/pgSQL, RAISE and error context
Previous Message Denis Kirjanov 2015-04-30 08:13:50 Re: [RFC] sepgsql: prohibit users to relabel objects