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

On Thu, May 17, 2018 at 11:56 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, May 17, 2018 at 2:10 AM, Ashutosh Bapat
> <ashutosh(dot)bapat(at)enterprisedb(dot)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.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company