|From:||Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Cc:||tgl(at)sss(dot)pgh(dot)pa(dot)us, ashutosh(dot)bapat(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: EvalPlanQual behaves oddly for FDW queries involving system columns|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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"
> 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
BTW, I revised docs a bit. Attached is an updated version of the patch.
|Next Message||Etsuro Fujita||2015-04-16 07:05:45||Re: inherit support for foreign tables|
|Previous Message||Michael Paquier||2015-04-16 06:46:32||Supporting src/test/modules in MSVC builds|