On 19/8/2024 21:16, Andrei Lepikhov wrote:
> On 19/8/2024 19:26, Tom Lane wrote:
>> Andrei Lepikhov <lepihov@gmail.com> writes:
>>> On 19/8/2024 18:36, Tom Lane wrote:
>>>> This seems like it's making assumptions it shouldn't about what
>>>> CustomScan does. If there's an argument for doing this, it should
>>>> be added to the adjacent comments.
>> The main reason I'm being sticky about this is that if we need to
>> allow CustomScan, then it seems likely that we also need to allow
>> ForeignScan, and maybe some other things, and then I start to
>> wonder if we should have any assertion at all about the child
>> plan type. So I want to actually understand what is the scenario
>> in which this will happen.
> I understand your point — the origins of ForeignScan and CustomScan are
> the same.
> However, we also have a difference: CustomScan can be executed locally
> and sometimes may allow volatile functions, CTE, and many other things
> in the underlying subtree. That's why we can't replay some cases with
> ForeignScan stuff.
> But ok, it make sense. I'll try to reproduce the case by employing
> ForeignScan.
Delving into the intricacies of ForeignScan, I came to the realization
that implementing a push-down of ROW() expression in FDW is no simple
feat. It requires a 'deparse' routine and other complex stuff. While
there have been the attempt [1], it appears to be in a raw state, making
it challenging to use.
Given that ForeignScan forms a flat target list for foreign scans and
assembles whole-row expressions locally, it's worth pondering: do we
really need to limit CustomScan in the same way? If yes, should we add a
'restrictions' section describing the limitations of the underlying
subtree's target list to the documentation?
[1]
https://www.postgresql.org/message-id/2253e9091b300d868d524c0943fa8796@postgrespro.ru
--
regards, Andrei Lepikhov
