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 <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'); > > > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
