Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options
От | Tom Lane |
---|---|
Тема | Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options |
Дата | |
Msg-id | 1694377.1759683105@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options (Álvaro Herrera <alvherre@kurilemu.de>) |
Список | pgsql-hackers |
=?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
В списке pgsql-hackers по дате отправления: