Hi Ashutosh, Thanks for the review!
(2014/11/10 20:05), Ashutosh Bapat wrote:
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.
Agreed. Will split the patch into two.
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?
ISTM it'd be better to tackle it separately because I feel that such an enforcement by the PG core would go too far. I'm also concerned about a possibility of impedance mismatching between such an enforcement and postgres_fdw, which sends the ctid column to the remote side internally when executing UPDATE/DELETE on foreign tables. See postgresPlanForeignModify and eg, deparseUpdateSql.
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
