Re: Inline non-SQL SRFs using SupportRequestSimplify - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Inline non-SQL SRFs using SupportRequestSimplify
Date
Msg-id CAFj8pRAbOK9Rp8SO+WSyrJ6mrTA-Mok_p4CxUW66Xxad11rPmQ@mail.gmail.com
Whole thread Raw
In response to Re: Inline non-SQL SRFs using SupportRequestSimplify  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


út 2. 12. 2025 v 7:05 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> ne 23. 11. 2025 v 1:45 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
>> So after some thought I renamed inline_set_returning_function to
>> inline_function_in_from, and made a bunch of other changes in names
>> and comments to line up with that.

> I checked this patch, and I think so using the body of the
> function foo_from_bar is very confusing.

Perhaps that example could use more documentation effort ...

> More correct form should be
>   RAISE EXCEPTION 'halt - should not be executed directly';

... but I don't agree with this at all.  We specifically do
not guarantee that replacement via SupportRequestSimplify
will be honored, and I think the same must be true for
SupportRequestInlineInFrom.  Otherwise we risk breaking
who-knows-how-many third-party tools, as well as cases
where the optimizer declines to inline (eg, because there
are volatile arguments).  Besides, what's the value?

My note is just for this test. 

I understand that the planner function can handle only some specific variants - and all others will be done by real execution.

and I was very interested in what is magic in forward, and the reality is very simple.

I think this feature can be very practical - but can be very messy for people who don't understand well to complete the picture. And it is a second level of overloading (what is byself dangerous for someone).

Regards

Pavel




 

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication
Next
From: Dilip Kumar
Date:
Subject: Re: Parallel Apply