On Saturday, September 13, 2025, PG Doc comments form <
[email protected]> wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/17/sql-createfunction.html
> Description:
>
> > This is effectively another way of declaring a named OUT parameter
>
> Actually OUT works twice slower in compare to RETURNS TABLE
> https://stackoverflow.com/q/79763947/4632019
>
> DB<>fiddle for [`OUT`](https://dbfiddle.uk/fz9L_wm0) and [`RETURNS
> TABLE`](https://dbfiddle.uk/uTkU1MT8) cases.
>
> *I hope after the fix, data centers will consume 2 times less electricity
>
>
The statement is not false - it contains an “except” clause that you’ve
ignored which makes it true for exactly this reason. The fact you are
comparing a set-returning function to one that doesn’t return a set has
invalidated the test.
The fundamental issue here is “select (composite_func()).*” where the
function is not set-returning if known to be broken - the “*” expansion
during planning results in the function being executed multiple times once
for each output column. (I may be missing some nuances here as, since the
inclusion of lateral joins, this almost never comes up anymore.)
Non-trivial function calls should be placed in the FROM clause of a query;
in part to ensure avoidance of this problematic behavior.
This is not at all limited to RLS.
In short, I don’t know how to improve the documentation to prevent people
from writing bad queries of this type. Concrete suggestions are welcome,
but removing this sentence, or re-wording it, doesn’t seem like it would
make any difference.
David J.
