Re: The document contains false statements
От | David G. Johnston |
---|---|
Тема | Re: The document contains false statements |
Дата | |
Msg-id | CAKFQuwYj6O1F4pFcpDX9x4QdtuBjKwt6KdzUxSswi9625Bg1ug@mail.gmail.com обсуждение исходный текст |
Ответ на | The document contains false statements (PG Doc comments form <noreply@postgresql.org>) |
Список | pgsql-docs |
On Saturday, September 13, 2025, PG Doc comments form <noreply@postgresql.org> 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.
В списке pgsql-docs по дате отправления: