Re: postgres_fdw behaves oddly - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: postgres_fdw behaves oddly
Date
Msg-id CAFjFpReZrMOy8p-hSdiLZ=uguvTaPQQWs5Qq19FsC9pOfo+myw@mail.gmail.com
Whole thread Raw
In response to Re: postgres_fdw behaves oddly  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: postgres_fdw behaves oddly  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
Since two separate issues 1. using reltargetlist instead of attr_needed and 2. system columns usage in FDW are being tackled here, we should separate the patch into two one for each of the issues.

While I agree that the system columns shouldn't be sent to the remote node, it doesn't look clear to me as to what would they or their values mean in the context of foreign data. Some columns like tableoid would have a value which is the OID of the foreign table, other system columns like xmin/xmax/ctid will have different meanings (or no meaning) depending upon the foreign data source. In case of later columns, each FDW would have its own way of defining that meaning (I guess). But in any case, I agree that we shouldn't send the system columns to the remote side.

Is there a way we can enforce this rule across all the FDWs? OR we want to tackle it separately per FDW?

On Tue, Oct 14, 2014 at 8:05 AM, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:
(2014/10/14 8:53), Robert Haas wrote:
On Mon, Oct 13, 2014 at 3:30 PM, Bruce Momjian <bruce@momjian.us> wrote:
Uh, where are we on this patch?

Probably it should be added to the upcoming CF.

Done.

https://commitfest.postgresql.org/action/patch_view?id=1599

Thanks,

Best regards,
Etsuro Fujita


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

pgsql-hackers by date:

Previous
From: Kouhei Kaigai
Date:
Subject: Re: [v9.5] Custom Plan API
Next
From: Andres Freund
Date:
Subject: Allow signal handlers to optionally use SA_SIGINFO information?