Re: Odd system-column handling in postgres_fdw join pushdown patch - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Odd system-column handling in postgres_fdw join pushdown patch
Date
Msg-id 20160406051359.GA1669886@tornado.leadboat.com
Whole thread Raw
In response to Re: Odd system-column handling in postgres_fdw join pushdown patch  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: Odd system-column handling in postgres_fdw join pushdown patch  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Tue, Apr 05, 2016 at 03:41:00PM +0900, Etsuro Fujita wrote:
> On 2016/03/29 15:37, Etsuro Fujita wrote:
> >I added two helper functions: GetFdwScanTupleExtraData and
> >FillFdwScanTupleSysAttrs.  The FDW author could use the former to get
> >info about system attributes other than ctids and oids in fdw_scan_tlist
> >during BeginForeignScan, and the latter to set values for these system
> >attributes during IterateForeignScan (InvalidTransactionId for
> >xmins/xmaxs, InvalidCommandId for cmins/cmaxs, and valid values for
> >tableoids).  Attached is a proposed patch for that.  I also slightly
> >simplified the changes to make_tuple_from_result_row and
> >conversion_error_callback made by the postgres_fdw join pushdown patch.
> >  What do you think about that?
> 
> I revised comments a little bit.  Attached is an updated version of the
> patch.  I think this issue should be fixed in advance of the PostgreSQL
> 9.6beta1 release.

Of the foreign table columns affected here, I bet only tableoid sees
non-negligible use.  Even tableoid is not very prominent, so I would not have
thought of this as a beta1 blocker.  What about this bug makes pre-beta1
resolution especially valuable?



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [PATH] Jsonb, insert a new value into an array at arbitrary position
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Support for N synchronous standby servers - take 2