From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, ashutosh(dot)bapat(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns |
Date: | 2019-02-28 18:18:36 |
Message-ID: | 20190228181836.pubst2yddu2werxx@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Thanks for the quick response.
On 2019-02-28 18:28:37 +0900, Etsuro Fujita wrote:
> > I'm currently
> > converting the EPQ machinery to slots, and in course of that I (with
> > Horiguchi-san's help), converted RefetchForeignRow to return a slot. But
> > there's currently no in-core user of this facility... I guess I can
> > rebase the preliminary postgres_fdw patch here, but it bitrotted
> > significantly.
>
> I'll rebase that patch and help the testing, if you want me to.
That'd be awesome.
> > I also feel like there should be some test coverage for
> > an API in a nontrivial part of the code...
>
> Yeah, but as mentioned above, the row-locking API is provided for FDWs
> operating against local storage, which we don't have in core, unfortunately.
Yea. file_fdw exists, but doesn't support modifications...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-02-28 18:20:20 | Re: plpgsql variable named as SQL keyword |
Previous Message | Tom Lane | 2019-02-28 18:16:02 | Re: Drop type "smgr"? |