Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

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

In response to

Responses

Browse pgsql-hackers by date

  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"?