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.
