Re: inherit support for foreign tables

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: alvherre(at)2ndquadrant(dot)com
Cc: Jim(dot)Nasby(at)BlueTreble(dot)com, fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp, tgl(at)sss(dot)pgh(dot)pa(dot)us, ashutosh(dot)bapat(at)enterprisedb(dot)com, hlinnakangas(at)vmware(dot)com, noah(at)leadboat(dot)com, shigeru(dot)hanada(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: inherit support for foreign tables
Date: 2015-04-15 00:35:05
Message-ID: 20150415.093505.266215018.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Before suppressing the symptom, I doubt the necessity and/or
validity of giving foreign tables an ability to be a parent. Is
there any reasonable usage for the ability?

I think we should choose to inhibit foreign tables from becoming
a parent rather than leaving it allowed then taking measures for
the consequent symptom.

regards,

At Tue, 14 Apr 2015 15:52:18 -0300, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote in <20150414185218(dot)GX4369(at)alvh(dot)no-ip(dot)org>
> Jim Nasby 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.
> >
> > What happens when the foreign side breaks the inheritance? Does the FDW
> > somehow know to check that fact for each query?
>
> This is a meaningless question. The remote tables don't have to have an
> inheritance relationship already; only the local side sees them as
> connected.
>
> 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.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2015-04-15 00:37:37 Re: Auditing extension for PostgreSQL (Take 2)
Previous Message Peter Eisentraut 2015-04-15 00:32:12 pgsql: Move pg_upgrade from contrib/ to src/bin/