Re: join pushdown and issue with foreign update

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: join pushdown and issue with foreign update
Date: 2021-06-02 07:43:40
Message-ID: CA+HiwqFX-9o2bvit7-YdL8qDp8P7PBBKsgqyDzKJn_O9Tw_M8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 2, 2021 at 6:32 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
> > I think a preferable fix involves making sure that the correct
> > record-type typmod is propagated to record_in in this context.
> > Alternatively, maybe we could insert the foreign table's rowtype
> > during execution of the input operation, without touching the
> > plan as such.
>
> Here's a draft-quality patch based on that idea.

This looks good to me. Yeah, I agree that reversing our decision to
mark row-id wholerow Vars in as RECORD rather than a specific reltype
will have to wait until we hear more complaints than just this one,
which seems fixable with a patch like this.

> It resolves
> the offered test case, but I haven't beat on it beyond that.

Given that we don't (no longer) support pushing down the join of child
target relations with other relations, I don't think we have other
cases that are affected at this point. I have a feeling that your
patch will have fixed things enough that the same problem will not
occur when we have join pushdown under UPDATE occurring in more cases.

--
Amit Langote
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-06-02 07:57:09 Re: Alias collision in `refresh materialized view concurrently`
Previous Message Andrey Lepikhov 2021-06-02 07:39:37 Re: join pushdown and issue with foreign update