Re: Fix misuse use of window_gettupleslot function (src/backend/executor/nodeWindowAgg.c)
| От | Ranier Vilela |
|---|---|
| Тема | Re: Fix misuse use of window_gettupleslot function (src/backend/executor/nodeWindowAgg.c) |
| Дата | |
| Msg-id | CAEudQAr4b85RXg8df9AxU+1rrgzSsLb+GXXTRLvb04UW_R=A6Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Fix misuse use of window_gettupleslot function (src/backend/executor/nodeWindowAgg.c) (Ranier Vilela <ranier.vf@gmail.com>) |
| Список | pgsql-hackers |
Em seg., 6 de out. de 2025 às 08:33, Ranier Vilela <ranier.vf@gmail.com> escreveu:
Em dom., 5 de out. de 2025 às 13:05, Tom Lane <tgl@sss.pgh.pa.us> escreveu:Ranier Vilela <ranier.vf@gmail.com> writes:
> Per Coverity.
> CID 1635309: (#1 of 1): Unchecked return value (CHECKED_RETURN)
> 7. check_return: Calling window_gettupleslot without checking return value
> (as is done elsewhere 8 out of 9 times).
Yeah, the security team's Coverity instance just whined about that
too. But isn't the correct behavior simply "return -1"?It seems to me a better option.It looks
to me like a failure should be interpreted as "row doesn't exist,
therefore it's not in frame".I also believe that the original author did not expect a failure here.There is a comment above that indicates that possibly a failure could also be the end of the partition.
What would be really useful is a test case that reaches this
condition. That would make it plain what to do.v1 patch attached.
It seems to me that this issue is being addressed in another thread. [1]
I'll withdraw these patch.
I'll withdraw these patch.
best regards,
Ranier Vilela
В списке pgsql-hackers по дате отправления: