Re: join pushdown and issue with foreign update - Mailing list pgsql-hackers

From Tom Lane
Subject Re: join pushdown and issue with foreign update
Date
Msg-id 451345.1622848984@sss.pgh.pa.us
Whole thread Raw
In response to Re: join pushdown and issue with foreign update  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes:
> On Wed, Jun 2, 2021 at 4:39 PM Andrey Lepikhov
> <a.lepikhov@postgrespro.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Next
From: Alvaro Herrera
Date:
Subject: Re: logical decoding bug: segfault in ReorderBufferToastReplace()