Re: Missing importing option of postgres_fdw - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: Missing importing option of postgres_fdw
Date
Msg-id 55547B06.3020005@lab.ntt.co.jp
Whole thread Raw
In response to Re: Missing importing option of postgres_fdw  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: Missing importing option of postgres_fdw  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
>> On 2015/04/30 2:10, Robert Haas wrote:
>>> On Mon, Apr 27, 2015 at 7:47 AM, Michael Paquier
>>> <michael.paquier@gmail.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.

On second thought, I noticed that as for this option, we cannot live 
without allowing IMPORT FOREIGN SCHEMA to return ALTER FOREIGN TABLE 
statements because we cannot declare the convalidated information in the 
CREATE FOREIGN TABLE statement.  So, I think we shoould also allow it to 
return ALTER FOREIGN TABLE statements.  Am I right?

Comments welcome.

Best regards,
Etsuro Fujita



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: multivariate statistics / patch v6
Next
From: Alexander Korotkov
Date:
Subject: Re: KNN-GiST with recheck