Horton

Re: Inline non-SQL SRFs using SupportRequestSimplify

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Paul A Jungwirth <pj@illuminatedcomputing.com>, Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-02T06:05:52Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add SupportRequestInlineInFrom planner support request.

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?

			regards, tom lane