On Friday, July 18, 2025, Tom Lane <t...@sss.pgh.pa.us> wrote:

> "David G. Johnston" <david.g.johns...@gmail.com> writes:
> > On Sunday, July 6, 2025, Paul Jungwirth <p...@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.


You would have said the same three releases ago and been wrong.  Seems like
you’d have to go back like 10 years when we figured out we messed up “case”
and 5 beyond that when we added the hooks.


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.


Then maybe we should use this patch to update the code comment (the part
about hooks is 15 years old but missed updating the code comment)  Then,
make this patch: see backend/optimizer/util/clauses.c#inline_function for a
description of the algorithm.

But I’d still be inclined to have a user-facing document for this, add a
note to the C code comment that it exists, and at least hopefully either
both C and Docs are updated or neither are.

David J.

Reply via email to