MIME-Version: 1.0
In-Reply-To: <175779557876.861.12514976006917547591@wrigleys.postgresql.org>
References: <175779557876.861.12514976006917547591@wrigleys.postgresql.org>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Sat, 13 Sep 2025 16:26:21 -0700
Message-ID: 
 <CAKFQuwYj6O1F4pFcpDX9x4QdtuBjKwt6KdzUxSswi9625Bg1ug@mail.gmail.com>
Subject: Re: The document contains false statements
To: "kes-kes@yandex.ru" <kes-kes@yandex.ru>,
	"pgsql-docs@lists.postgresql.org" <pgsql-docs@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000002a82bf063eb71994"
Archived-At: 
 <https://www.postgresql.org/message-id/CAKFQuwYj6O1F4pFcpDX9x4QdtuBjKwt6KdzUxSswi9625Bg1ug%40mail.gmail.com>
Precedence: bulk

--0000000000002a82bf063eb71994
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =E2=80=9Cexcept=E2=80=9D clause=
 that you=E2=80=99ve
ignored which makes it true for exactly this reason.  The fact you are
comparing a set-returning function to one that doesn=E2=80=99t return a set=
 has
invalidated the test.

The fundamental issue here is =E2=80=9Cselect (composite_func()).*=E2=80=9D=
 where the
function is not set-returning if known to be broken - the =E2=80=9C*=E2=80=
=9D 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=E2=80=99t 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=E2=80=99t seem like it =
would
make any difference.

David J.

--0000000000002a82bf063eb71994
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Saturday, September 13, 2025, PG Doc comments form &lt;<a href=3D"mailto=
:noreply@postgresql.org">noreply@postgresql.org</a>&gt; wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">The following documentation comment has been logged o=
n the website:<br>
<br>
Page: <a href=3D"https://www.postgresql.org/docs/17/sql-createfunction.html=
" target=3D"_blank">https://www.postgresql.org/<wbr>docs/17/sql-createfunct=
ion.<wbr>html</a><br>
Description:<br>
<br>
&gt; This is effectively another way of declaring a named OUT parameter<br>
<br>
Actually OUT works twice slower in compare to RETURNS TABLE<br>
<a href=3D"https://stackoverflow.com/q/79763947/4632019" target=3D"_blank">=
https://stackoverflow.com/q/<wbr>79763947/4632019</a><br>
<br>
DB&lt;&gt;fiddle for [`OUT`](<a href=3D"https://dbfiddle.uk/fz9L_wm0" targe=
t=3D"_blank">https://dbfiddle.uk/<wbr>fz9L_wm0</a>) and [`RETURNS<br>
TABLE`](<a href=3D"https://dbfiddle.uk/uTkU1MT8" target=3D"_blank">https://=
dbfiddle.uk/<wbr>uTkU1MT8</a>) cases.<br>
<br>
*I hope after the fix, data centers will consume 2 times less electricity<b=
r><br>
</blockquote><div><br></div><div>The statement is not false - it contains a=
n =E2=80=9Cexcept=E2=80=9D clause that you=E2=80=99ve ignored which makes i=
t true for exactly this reason.=C2=A0 The fact you are comparing a set-retu=
rning function to one that doesn=E2=80=99t return a set has invalidated the=
 test.</div><div><br></div><div>The fundamental issue here is =E2=80=9Csele=
ct (composite_func()).*=E2=80=9D where the function is not set-returning if=
 known to be broken - the =E2=80=9C*=E2=80=9D expansion during planning res=
ults in the function being executed multiple times once for each output col=
umn. (I may be missing some nuances here as, since the inclusion of lateral=
 joins, this almost never comes up anymore.)<br></div><div><br></div><div>N=
on-trivial function calls should be placed in the FROM clause of a query; i=
n part to ensure avoidance of this problematic behavior.</div><div><br></di=
v><div>This is not at all limited to RLS.</div><div><br></div><div>In short=
, I don=E2=80=99t know how to improve the documentation to prevent people f=
rom writing bad queries of this type.=C2=A0 Concrete suggestions are welcom=
e, but removing this sentence, or re-wording it, doesn=E2=80=99t seem like =
it would make any difference.</div><div><br></div><div>David J.</div><div><=
br></div>

--0000000000002a82bf063eb71994--