From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, 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-04 23:23:04 |
Message-ID: | 451345.1622848984@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> On Wed, Jun 2, 2021 at 4:39 PM Andrey Lepikhov
> <a(dot)lepikhov(at)postgrespro(dot)ru> wrote:
>> 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.
I thought about this for awhile and I don't think it's a real concern.
There's nothing stopping us from pushing an expression of the form
"func(row(...))" or "row(...) op row(...)", because we're not asking
to retrieve the value of the ROW() expression. Whether the remote
server can handle that is strictly its concern. (Probably, it's
going to do something involving a locally-assigned typmod to keep
track of the rowtype, but it's not our problem.) Where things get
sticky is if we try to *retrieve the value* of a ROW() expression.
And except in this specific context, I don't see why we'd do that.
There's no advantage compared to retrieving the component Vars
or expressions.
> ... I wonder if it would make sense to also
> check varattno == 0 here somewhere for good measure.
Yeah, I considered doing that but left it off in this version.
It's not clear to me how there could be a table column of type RECORD,
so it seemed unnecessary. On the other hand, it's also cheap
insurance, so I'll put it back.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2021-06-04 23:35:33 | Re: logical decoding bug: segfault in ReorderBufferToastReplace() |
Previous Message | Alvaro Herrera | 2021-06-04 23:21:11 | Re: Move pg_attribute.attcompression to earlier in struct for reduced size? |