Re: join pushdown and issue with foreign update

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: join pushdown and issue with foreign update
Дата
Msg-id 451345.1622848984@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: join pushdown and issue with foreign update  (Amit Langote <amitlangote09@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: logical decoding bug: segfault in ReorderBufferToastReplace()