| From: | Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru> |
| Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: join pushdown and issue with foreign update |
| Date: | 2021-06-02 07:39:37 |
| Message-ID: | f0e58ebd-e5e6-e905-f3ab-a609272e6f08@postgrespro.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2/6/21 02:32, Tom Lane 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. It resolves
> the offered test case, but I haven't beat on it beyond that.
>
> regards, tom lane
>
I played with your patch and couldn't find any errors. But what if ROW
operation were allowed to be pushed to a foreign server?
Potentially, I can imagine pushed-down JOIN with arbitrary ROW function
in its target list.
Amit's approach looks more safe for me.
--
regards,
Andrey Lepikhov
Postgres Professional
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2021-06-02 07:43:40 | Re: join pushdown and issue with foreign update |
| Previous Message | houzj.fnst@fujitsu.com | 2021-06-02 07:30:32 | RE: Parallel INSERT SELECT take 2 |