pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17805: Unexpected results when bounds of FOR loop use non-integer numbers
2+ messages / 2 participants
[nested] [flat]
* BUG #17805: Unexpected results when bounds of FOR loop use non-integer numbers
@ 2023-02-22 14:23 PG Bug reporting form <noreply@postgresql.org>
2023-02-22 15:01 ` Re: BUG #17805: Unexpected results when bounds of FOR loop use non-integer numbers David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 2+ messages in thread
From: PG Bug reporting form @ 2023-02-22 14:23 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: jiangshan.liu@tju.edu.cn
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-L...
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: BUG #17805: Unexpected results when bounds of FOR loop use non-integer numbers
2023-02-22 14:23 BUG #17805: Unexpected results when bounds of FOR loop use non-integer numbers PG Bug reporting form <noreply@postgresql.org>
@ 2023-02-22 15:01 ` David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 0 replies; 2+ messages in thread
From: David G. Johnston @ 2023-02-22 15:01 UTC (permalink / raw)
To: jiangshan.liu@tju.edu.cn; pgsql-bugs@lists.postgresql.org
On Wed, Feb 22, 2023 at 7:46 AM PG Bug reporting form <
noreply@postgresql.org> wrote:
> 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?
>
No, a loop needs a discrete data type so that a step makes sense. So
integer it is.
postgres=# select 2.5::integer;
int4
------
3
(1 row)
> 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.
That is the nature of programming. Test your code and don't write stuff
that doesn't actually make sense.
> 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.
In retrospect this probably would have been a better outcome. Introducing
an error/change now seems problematic though.
So, yes, if either bound is not an integer the value will be coerced to
become an integer by the normal casting rules between those types.
David J.
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2023-02-22 15:01 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-02-22 14:23 BUG #17805: Unexpected results when bounds of FOR loop use non-integer numbers PG Bug reporting form <noreply@postgresql.org>
2023-02-22 15:01 ` David G. Johnston <david.g.johnston@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox