From: Tom Lane <tgl@sss.pgh.pa.us>
To: Paul A Jungwirth <pj@illuminatedcomputing.com>
cc: Heikki Linnakangas <hlinnaka@iki.fi>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Inline non-SQL SRFs using SupportRequestSimplify
In-reply-to: 
 <CA+renyXxanvX8rnrqTNkZt1r9=rm59MHSG4DDVfsV2aUGe3dUQ@mail.gmail.com>
References: <09de6afa-c33d-4d94-a5cb-afc6cea0d2bb@illuminatedcomputing.com>
 <ffd7937d-190c-4f09-9418-5345728b45c4@iki.fi>
 <1755478.1722020334@sss.pgh.pa.us>
 <956f8a6f-32a7-49ab-92a3-dca5c8afe112@illuminatedcomputing.com>
 <1466725.1725381721@sss.pgh.pa.us>
 <33b10538-2c88-4278-a65f-0c1e6f265cb7@illuminatedcomputing.com>
 <737313.1752528083@sss.pgh.pa.us>
 <CA+renyXxanvX8rnrqTNkZt1r9=rm59MHSG4DDVfsV2aUGe3dUQ@mail.gmail.com>
Comments: In-reply-to Paul A Jungwirth <pj@illuminatedcomputing.com>
	message dated "Fri, 08 Aug 2025 14:46:01 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <440457.1763858681.1@sss.pgh.pa.us>
Date: Sat, 22 Nov 2025 19:44:41 -0500
Message-ID: <440458.1763858681@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/440458.1763858681%40sss.pgh.pa.us>
Precedence: bulk

Paul A Jungwirth <pj@illuminatedcomputing.com> writes:
> The reason for supporting more than SQL functions is to let you
> construct the query dynamically, e.g. with user-supplied table/column
> names, or to only include some expensive filters if needed. This would
> be great for building functions that implement temporal
> outer/semi/antijoin. Another use-case I personally have, which I think
> is quite common, is building "parameterized views" for permissions
> checks, e.g. visible_sales(user). In that case we may only need to
> include certain joins if the user belongs to certain roles (e.g. a
> third-party sales rep).

I went through this again, and committed it with a bunch of
mostly-cosmetic changes.  In particular, it seemed like talking
about inlining "set-returning functions" is no longer really on-point,
since this mechanism is perfectly capable of inlining non-SRFs.
(The reason we haven't done that for SQL functions is mainly that
we didn't feel like doing the analysis necessary to prove that a
SELECT will return exactly one row, which would be necessary to
maintain semantic equivalence for a non-SRF after inlining.
The easy cases of that, such as "SELECT expression", are already
sufficiently handled by regular inlining.)

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.

Thanks for working on this!  I know it's been a long slog.

			regards, tom lane