Re: postgres_fdw behaves oddly

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