Re: BUG #18101: 'RAISE LOG ...' with omitted trailing ';' does not throw syntax error in certain situations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jasonscrumbs+postgres(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18101: 'RAISE LOG ...' with omitted trailing ';' does not throw syntax error in certain situations
Date: 2023-09-09 20:54:40
Message-ID: 2261324.1694292880@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-09-09 22:56:42 Re: BUG #18097: Immutable expression not allowed in generated at
Previous Message Jeff Davis 2023-09-09 20:42:46 [16] ALTER SUBSCRIPTION ... SET (run_as_owner = ...) is a no-op