Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Álvaro Herrera <alvherre@kurilemu.de>

Cc: Tatsuo Ishii <ishii@postgresql.org>, ojford@gmail.com, peter@eisentraut.org, li.evan.chao@gmail.com, krasiyan@gmail.com, vik@postgresfriends.org, andrew@tao11.riddles.org.uk, david@fetter.org, pgsql-hackers@lists.postgresql.org

Date: 2025-10-05T16:51:45Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix coding style with "else".
- 20628b62e46e 19 (unreleased) landed
Fix multi WinGetFuncArgInFrame/Partition calls with IGNORE NULLS.
- 2d7b247cb414 19 (unreleased) landed
Fix Coverity issue reported in commit 2273fa32bce.
- dd766a441d69 19 (unreleased) landed
Use ereport rather than elog in WinCheckAndInitializeNullTreatment.
- 5f3808646f67 19 (unreleased) landed
Avoid uninitialized-variable warnings from older compilers.
- 71540dcdcb22 19 (unreleased) cited
Fix Coverity issues reported in commit 25a30bbd423.
- 2273fa32bce7 19 (unreleased) landed
Improve EXPLAIN's display of window functions.
- 8b1b342544b6 18.0 cited
Automatically generate node support functions
- 964d01ae90c3 16.0 cited

=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> I just noticed this compiler warning in a CI run,

> [16:06:29.920] ../src/backend/executor/nodeWindowAgg.c:3820:16: warning: ‘datum’ may be used uninitialized [-Wmaybe-uninitialized]
> [16:06:29.920]  3820 |         return datum;
> [16:06:29.920]       |                ^~~~~

Yeah, I can easily believe that a compiler running at relatively low
optimization level wouldn't make the connection that the NN_NOTNULL
case must perform the "prepare to exit this loop" bit if the loop
will be exited this time.  But there's another thing that is
confusing: the NN_NULL case certainly looks like it's expecting
to exit the loop, but that "break" will only get out of the switch
not the loop.  Moreover, the NN_NULL case looks like it'd fail
to notice end-of-frame.  And it's not entirely clear what the
default case thinks it's doing either.

In short, this loop is impossible to understand, and the lack of
comments doesn't help.  Even if it's not actually buggy, it
needs to be rewritten in a way that helps readers and compilers
see that it's not buggy.  I think it might help to separate the
detection of null-ness and fetching of the datum value (if required)
from the loop control logic.

			regards, tom lane