Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server
Date
Msg-id 5C5C2AB6.9030809@lab.ntt.co.jp
Whole thread Raw
In response to Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server
List 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



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Protect syscache from bloating with negative cache entries
Next
From: "Tels"
Date:
Subject: Re: Tighten up a few overly lax regexes in pg_dump's tap tests