From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Jim Nasby <Jim.Nasby@BlueTreble.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Noah Misch <noah@leadboat.com>
Cc: Shigeru Hanada <shigeru.hanada@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: inherit support for foreign tables
Date: Thu, 16 Apr 2015 12:20:47 +0900
Message-ID: <552F2A8F.2090406@lab.ntt.co.jp> (raw)
In-Reply-To: <20150414185218.GX4369@alvh.no-ip.org>
References: <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>
<19367.1419262577@sss.pgh.pa.us>
<54B76DD2.1040106@lab.ntt.co.jp>
<54E6DB4E.40801@lab.ntt.co.jp>
<21104.1427047056@sss.pgh.pa.us>
<552CF0B6.8010006@lab.ntt.co.jp>
<552D4EE3.3060708@BlueTreble.com>
<20150414185218.GX4369@alvh.no-ip.org>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2015/04/15 3:52, Alvaro Herrera wrote:
>> On 4/14/15 5:49 AM, Etsuro Fujita wrote:
>>> postgres=# create foreign table ft1 (c1 int) server myserver options
>>> (table_name 't1');
>>> CREATE FOREIGN TABLE
>>> postgres=# create foreign table ft2 (c1 int) server myserver options
>>> (table_name 't2');
>>> CREATE FOREIGN TABLE
>>> postgres=# alter foreign table ft2 inherit ft1;
>>> ALTER FOREIGN TABLE
>>> postgres=# select * from ft1 for update;
>>> ERROR: could not find junk tableoid1 column
>>>
>>> I think this is a bug. Attached is a patch fixing this issue.
> I think the real question is whether we're now (I mean after this patch)
> emitting useless tableoid columns that we didn't previously have. I
> think the answer is yes, and if so I think we need a smaller comb to fix
> the problem. This one seems rather large.
My answer for that would be *no* because I think tableoid would be
needed for EvalPlanQual checking in more complex SELECT FOR UPDATE on
the inheritance or UPDATE/DELETE involving the inheritance as a source
table. Also, if we allow the FDW to change the behavior of SELECT FOR
UPDATE so as to match the local semantics exactly, which I'm working on
in another thread, I think tableoid would also be needed for the actual
row locking.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: fujita.etsuro@lab.ntt.co.jp, alvherre@2ndquadrant.com, Jim.Nasby@BlueTreble.com, tgl@sss.pgh.pa.us, ashutosh.bapat@enterprisedb.com, horiguchi.kyotaro@lab.ntt.co.jp, hlinnakangas@vmware.com, noah@leadboat.com, shigeru.hanada@gmail.com
Subject: Re: inherit support for foreign tables
In-Reply-To: <552F2A8F.2090406@lab.ntt.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox