Re: Problem while updating a foreign table pointing to apartitioned table on foreign server

At Fri, 18 May 2018 10:19:30 +0530, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote in
<CAFjFpRe5KBBXzio-1iCzmH35kxYy90z6ewLU+VPtM0u=kH-ubw@mail.gmail.com>
ashutosh.bapat> On Thu, May 17, 2018 at 11:56 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> > On Thu, May 17, 2018 at 2:10 AM, Ashutosh Bapat
> > <ashutosh.bapat@enterprisedb.com> wrote:
> >> The second would mean that SELECT * from foreign table reports
> >> remotetableoid as well, which is awkward.
> >
> > No it wouldn't.  You'd just make the additional column resjunk, same
> > as we do for wholerow.
> 
> You suggested
> --
> > I think that the place to start would be to change this code to use
> > something other than TableOidAttributeNumber:
> >
> > +       var = makeVar(parsetree->resultRelation,
> > +                                 TableOidAttributeNumber,
> > +                                 OIDOID,
> > +                                 -1,
> > +                                 InvalidOid,
> > +                                 0);
> --
> 
> Wholerow has its own attribute number 0, ctid has its attribute number
> -1. So we can easily create Vars for those and add resjunk entries in
> the targetlist. But a "remotetableoid" doesn't have an attribute
> number yet! Either it has to be a new system column, which I and
> almost everybody here is opposing, or it has to be a user defined
> attribute, with an entry in pg_attributes table. In the second case,
> how would one make that column resjunk? I don't see any third
> possibility.

I have reached to the same thought.
  
The point here is that it is a base relation, which is not
assumed to have additional columns not in its definition,
including nonsystem junk columns. I'm not sure but it seems not
that simple to give base relations an ability to have junk
columns.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center