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
