Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involvingsystem columns - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involvingsystem columns
Date
Msg-id 20190228181836.pubst2yddu2werxx@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involvingsystem columns  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involvingsystem columns  (Andres Freund <andres@anarazel.de>)
List 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Drop type "smgr"?
Next
From: Tom Lane
Date:
Subject: Re: plpgsql variable named as SQL keyword