PG Bug reporting form <noreply@postgresql.org> writes:
> do $$
> begin
> raise log 'test %', '01'
> delete from error_test_tt where val = 1;
> end
> $$;
I don't think this is a bug, although I agree it's surprising.
You've managed to hit what seems to me like a fairly narrow
ambiguous case. The stuff between the comma and the semicolon
is parsed as a plpgsql expression, which for historical reasons
is defined as "almost anything that could follow SELECT" [1].
So, if we were to write
SELECT '01' delete from error_test_tt where val = 1;
would we get a syntax error? No, we would not.
=# SELECT '01' delete from error_test_tt where val = 1;
delete
--------
01
(1 row)
The "delete" is interpreted as a column label, thanks to one of
the SQL committee's poorer decisions which was to allow omission
of AS in SELECT target lists (even before labels that are keywords),
and then the rest of it is a perfectly valid FROM and WHERE clause
for SELECT. Nor, in this specific example, do we hit the semantic
constraints that the "expression" must produce one column and not
more than one row.
I don't think there's anything we can do to tighten this up that
isn't going to result in breaking a lot of people's plpgsql code.
The fact that a plpgsql expression can be more than just a scalar
expression has been used/abused all over the place for decades.
We don't even speak disapprovingly of it in the docs (again, [1]).
regards, tom lane
[1] https://www.postgresql.org/docs/current/plpgsql-expressions.html
