public inbox for [email protected]
help / color / mirror / Atom feedBUG: PL/pgSQL FOREACH misparses variable named "slice" with SLICE clause
2+ messages / 2 participants
[nested] [flat]
* BUG: PL/pgSQL FOREACH misparses variable named "slice" with SLICE clause
@ 2026-04-15 18:56 Leendert Gravendeel <[email protected]>
2026-04-17 15:16 ` Re: BUG: PL/pgSQL FOREACH misparses variable named "slice" with SLICE clause Tom Lane <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Leendert Gravendeel @ 2026-04-15 18:56 UTC (permalink / raw)
To: pgsql-bugs
Hello,
I believe I have found a parser issue in PL/pgSQL involving the
FOREACH ... SLICE syntax.
Version:
PostgreSQL 18 (reproduced on current release)
Description:
When using FOREACH with the SLICE clause, a loop variable named
`slice` is misinterpreted as the SLICE keyword, causing the statement
to fail. Renaming the variable to anything else makes the function
work as expected.
Reproduction:
CREATE FUNCTION test_slice_conflict() RETURNS text
LANGUAGE plpgsql AS $$
DECLARE
slice integer[];
arr integer[] := ARRAY[[1,2],[3,4]];
BEGIN
FOREACH slice SLICE 1 IN ARRAY arr LOOP
END LOOP;
RETURN 'ok';
END;
$$;
Observed behavior:
The function fails to compile due to incorrect parsing of `slice`
as the SLICE keyword.
Expected behavior:
`slice` should be treated as a normal identifier (loop variable),
and the function should compile and run successfully.
Additional notes:
- Renaming the variable (e.g. to `abc`) makes the function work.
- This suggests a keyword/identifier ambiguity where the parser
prefers the SLICE keyword in this context.
Given that the documentation describes the FOREACH target as a
regular variable, this behavior seems unintended.
Please let me know if additional information is needed.
Best regards,
Leendert Gravendeel
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: BUG: PL/pgSQL FOREACH misparses variable named "slice" with SLICE clause
2026-04-15 18:56 BUG: PL/pgSQL FOREACH misparses variable named "slice" with SLICE clause Leendert Gravendeel <[email protected]>
@ 2026-04-17 15:16 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2026-04-17 15:16 UTC (permalink / raw)
To: Leendert Gravendeel <[email protected]>; +Cc: pgsql-bugs
Leendert Gravendeel <[email protected]> writes:
> When using FOREACH with the SLICE clause, a loop variable named
> `slice` is misinterpreted as the SLICE keyword, causing the statement
> to fail. Renaming the variable to anything else makes the function
> work as expected.
So, um, don't do that. PL/pgSQL will let you use (many of) its keywords
as variable names, but once you declare such a variable, the word will
be taken as a variable reference not as a keyword for the rest of the
block. So what the parser is seeing here is
FOREACH variable variable 1 IN ARRAY variable LOOP
and it naturally doesn't like that. You could also break this
statement by making a variable named "array", for example.
(But not "foreach", "in", or "loop", as those are reserved words.)
Not sure how well this behavior is documented. I think there are
a small number of exceptions, in places where the scanner can know
that the next word must be a keyword, but most unreserved keywords
work this way. The only other thing we could do is make such keywords
fully reserved, which would break legacy code that uses "slice" or
whatever as a variable name without knowledge of the new SLICE syntax.
So we generally try to make newly-added keywords unreserved; this
ambiguity seems the lesser evil.
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-04-17 15:16 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-04-15 18:56 BUG: PL/pgSQL FOREACH misparses variable named "slice" with SLICE clause Leendert Gravendeel <[email protected]>
2026-04-17 15:16 ` Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox