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

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, ashutosh(dot)bapat(at)enterprisedb(dot)com, alvherre(at)2ndquadrant(dot)com, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Problem while updating a foreign table pointing to a partitioned table on foreign server
Date: 2019-02-07 12:55:18
Message-ID: 5C5C2AB6.9030809@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(2019/02/02 10:21), Michael Paquier wrote:
> On Fri, Nov 16, 2018 at 01:35:15PM -0500, Tom Lane wrote:
>> I wonder whether we'd be better off thinking of a way to let FDWs
>> invent additional system column IDs for their tables, so that
>> something like a remote table OID could be represented in the
>> natural way as a Var with negative varattno. This'd potentially
>> also be a win for FDWs whose underlying storage has a row identifier,
>> but it's not of type "tid". Instead of trying to shoehorn their
>> row ID into SelfItemPointerAttributeNumber, they could define a
>> new system column that has a more appropriate data type. Admittedly
>> there'd be some infrastructure work to do to make this happen, maybe
>> a lot of it; but it's a bullet we really need to bite at some point.
>
> This patch got zero input for the last couple of months. As it is
> classified as bug fix, I have moved it to next CF, waiting on author.
> Fujita-san, are you planning to look at it?

I 100% agree with Tom, and actually, I tried to address his comments,
but I haven't come up with a clear solution for that yet. I really want
to address this, but I won't have much time to work on that at least
until after this development cycle, so what I'm thinking is to mark this
as Returned with feedback, or if possible, to move this to the 2019-07 CF.

My apologies for the late reply.

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tels 2019-02-07 12:55:32 Re: Tighten up a few overly lax regexes in pg_dump's tap tests
Previous Message Kyotaro HORIGUCHI 2019-02-07 12:18:45 Re: Protect syscache from bloating with negative cache entries