Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server
От | Ashutosh Bapat |
---|---|
Тема | Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server |
Дата | |
Msg-id | CAFjFpRe5KBBXzio-1iCzmH35kxYy90z6ewLU+VPtM0u=kH-ubw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Problem while updating a foreign table pointing to apartitioned table on foreign server
|
Список | pgsql-hackers |
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. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: