From: Tom Lane <tgl@sss.pgh.pa.us>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
cc: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>,
 Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
 Heikki Linnakangas <hlinnakangas@vmware.com>,
 Noah Misch <noah@leadboat.com>, Shigeru Hanada <shigeru.hanada@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: inherit support for foreign tables
In-reply-to: <5497FE79.7090804@lab.ntt.co.jp>
References: <543D0261.6020803@lab.ntt.co.jp> <54461BEB.9000707@lab.ntt.co.jp>
 <5449EE98.1040704@lab.ntt.co.jp>
 <20141107.145713.169337282.horiguchi.kyotaro@lab.ntt.co.jp>
 <545CB4A2.1030303@lab.ntt.co.jp>
 <CAFjFpRcVLtU6jE8h_N1Rc+Y-pDFbmR7YvBvxOXg6aTFrbZ1Z8Q@mail.gmail.com>
 <54645499.7050709@lab.ntt.co.jp>
 <CAFjFpRcBFVO0YP0nmfygpJOFfWKMkAN1Z8JmrkwyEWXDyMt5Hw@mail.gmail.com>
 <CAFjFpRcd=F8Jqx+9yioHKVUA71LXBxO41ia61acjzyzQ4MZqVQ@mail.gmail.com>
 <5476FB4B.9060705@lab.ntt.co.jp>
 <CAFjFpRd6PR3Seg8D3t-XcXGxXyb+p2WDsk_wBGge7b=PyzP_Qw@mail.gmail.com>
 <5487BB9D.7070605@lab.ntt.co.jp> <30555.1418853840@sss.pgh.pa.us>
 <5497FE79.7090804@lab.ntt.co.jp>
Comments: In-reply-to Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
 message dated "Mon, 22 Dec 2014 20:20:25 +0900"
Date: Mon, 22 Dec 2014 10:36:17 -0500
Message-ID: <19367.1419262577@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
> I haven't done anything about the issue that postgresGetForeignPlan() is
> using get_parse_rowmark(), discussed in eg, [2].  Tom, will you work on
> that?

Yeah, we need to do something about the PlanRowMark data structure.
Aside from the pre-existing issue in postgres_fdw, we need to fix it
to support inheritance trees in which more than one rowmark method
is being used.  That rte.hasForeignChildren thing is a crock, and
would still be a crock even if it were correctly documented as being
a planner temporary variable (rather than the current implication that
it's always valid).  RangeTblEntry is no place for planner temporaries.

The idea I'd had about that was to convert the markType field into a
bitmask, so that a parent node's markType could represent the logical
OR of the rowmark methods being used by all its children.  I've not
attempted to code this up though, and probably won't get to it until
after Christmas.  One thing that's not clear is what should happen
with ExecRowMark.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers