Re: Documenting inlining SQL functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Documenting inlining SQL functions
Date
Msg-id 2228148.1752894494@sss.pgh.pa.us
Whole thread Raw
In response to Re: Documenting inlining SQL functions  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Documenting inlining SQL functions
Re: Documenting inlining SQL functions
Re: Documenting inlining SQL functions
List pgsql-hackers
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Sunday, July 6, 2025, Paul Jungwirth <pj@illuminatedcomputing.com> wrote:
>> The second patch adds a new <sect2> explaining how we inline SQL
>> functions: both single-result and set-returning. Since this happens
>> automatically, it makes a nice progression with the (easy) declarative
>> annotations and the (hard) support functions.

> The fact that attaching a set clause to the function definition (i.e.,
> proconfig) prevents inlining is missing from this description.

TBH, I think trying to document this behavior at this level of detail
will be a disaster.  Our track record for keeping documentation in
sync with code is awful, and what exactly will make this area better
than average?  Even if this text is 100% accurate today, I'll bet a
good lunch that it will be wrong in two or three releases.

Our attitude for questions at the level of detail that this is
trying to cover has mostly been "someone who cares can go read
the code".  I grant that that's not a great answer, but it's
largely stood the test of time.

I think it's reasonable to document the fact that we can do SQL
function inlining in some cases, but not to try to specify which
cases those are in exhaustive detail.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Documenting inlining SQL functions
Next
From: Peter Geoghegan
Date:
Subject: Re: index prefetching