Re: EvalPlanQual behaves oddly for FDW queries involving system columns

On 2015/04/15 2:27, Jim Nasby wrote:
> On 4/14/15 1:05 AM, Kyotaro HORIGUCHI wrote:
>> As an example, the following operations cause an "unexpected"
>> result.

> Those results are indeed surprising, but since we allow it in a direct
> connection I don't see why we wouldn't allow it in the Postgres FDW...
>
> As for the FDW not knowing about keys, why would it need to? If you try
> to do something illegal it's the remote side that should throw the
> error, not the FDW.
>
> Of course, if you try to do a locking operation on an FDW that doesn't
> support it, the FDW should throw an error... but that's different.

Ah, you are right.  FOR NO KEY UPDATE and FOR KEY SHARE would be useful
in the Postgres FDW if we assume the user performs those properly based
on information about keys for a remote table.

Sorry, my explanation was not correct, but I want to make it clear that
the proposed patch also allows the FDW to change the behavior of FOR NO
KEY UPDATE and/or FOR KEY SHARE row locking so as to match the local
semantics exactly.

BTW, I revised docs a bit.  Attached is an updated version of the patch.

Best regards,
Etsuro Fujita