Thread

Re: Inline non-SQL SRFs using SupportRequestSimplify

Pavel Stehule <pavel.stehule@gmail.com> — 2025-12-02T06:14:06Z

ú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.

But this is really confusing - I read the blog
https://www.thatguyfromdelhi.com/2025/11/teaching-query-planner-to-see-inside-c.html
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
>