BUG #17805: Unexpected results when bounds of FOR loop use non-integer numbers
От | PG Bug reporting form |
---|---|
Тема | BUG #17805: Unexpected results when bounds of FOR loop use non-integer numbers |
Дата | |
Msg-id | 17805-274c2f3650367138@postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #17805: Unexpected results when bounds of FOR loop use non-integer numbers
|
Список | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 17805 Logged by: Jiangshan Liu Email address: jiangshan.liu@tju.edu.cn PostgreSQL version: 15.2 Operating system: Ubuntu 18.04 Description: I got unexpected results when I ran this PL/pgSQL function: CREATE FUNCTION test() RETURNS void AS $$ BEGIN FOR i IN 1 .. 0.5*5 LOOP raise notice '%', i; END LOOP; END; $$ LANGUAGE plpgsql; SELECT * FROM test(); The result of the execution is: NOTICE: 1 NOTICE: 2 NOTICE: 3 I think this result is unexpected because the last round of loop variable is beyond the specified upper bound of the loop. Is this a bug in a FOR loop? I noticed that the documentation describes it this way: The two expressions giving the lower and upper bound of the range are evaluated once when entering the loop[1]. However, the documentation does not mention how the upper and lower bounds were evaluated. Based on the analysis of the execution, it appears that the FOR loop seems to implicitly convert the NUMERIC type upper bound value (2.5) to INT type value (3) by rounding. But this seems to cause incomprehensible results. If it is unsafe to take values outside the upper and lower bounds of the loop, then this will lead to unintended consequences. Is this implicit type conversion necessary? I think there are two better ways to do it. One is to report errors directly to the user. Pascal and Ada languages support FOR loops of integer variant, and they throw errors to the user when there are non-integer variant in the upper and lower bounds of the loop. The second is to use an implicit type conversion from integer to non-integer, followed by a comparison, to ensure that the loop does not exceed the upper and lower bounds, just like other procedural languages (e.g. C, Python, etc.). [1] https://www.postgresql.org/docs/current/plpgsql-control-structures.html#PLPGSQL-CONTROL-STRUCTURES-LOOPS:~:text=of%20the%20range-,are%20evaluated%20once,-when%20entering%20the
В списке pgsql-bugs по дате отправления: