Re: Documenting inlining SQL functions

On Fri, Jul 18, 2025 at 9:08 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Sunday, July 6, 2025, Paul Jungwirth <pj(at)illuminatedcomputing(dot)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.
>

Yeah.
I'm still contemplating my goofy answer to the inlining gripe on a recent
thread..oh well :).

Maybe it might be more helpful and future proof to, rather than bullet
point list the mechanics that prevent inlining, provide some lightly sanded
down advice on how certain mechanics can prevent inlining along with some
advice on how to detect if a particular function is inlined based on
explain output.

merlin