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.


At Tue, 14 Apr 2015 15:52:18 -0300, Alvaro Herrera <alvhe...@2ndquadrant.com> 
wrote in <20150414185218.gx4...@alvh.no-ip.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');
> > > postgres=# create foreign table ft2 (c1 int) server myserver options
> > > (table_name 't2');
> > > postgres=# alter foreign table ft2 inherit ft1;
> > > 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

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

Reply via email to