From: Tom Lane <tgl@sss.pgh.pa.us>
To: jasonscrumbs+postgres@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18101: 'RAISE LOG ...' with omitted trailing ';' does not
 throw syntax error in certain situations
In-reply-to: <18101-10af06fb12aeab34@postgresql.org>
References: <18101-10af06fb12aeab34@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Sat, 09 Sep 2023 02:29:29 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2261323.1694292880.1@sss.pgh.pa.us>
Date: Sat, 09 Sep 2023 16:54:40 -0400
Message-ID: <2261324.1694292880@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2261324.1694292880%40sss.pgh.pa.us>
Precedence: bulk

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