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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #18101: 'RAISE LOG ...' with omitted trailing ';' does not throw syntax error in certain situations
Дата
Msg-id 2261324.1694292880@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #18101: 'RAISE LOG ...' with omitted trailing ';' does not throw syntax error in certain situations  (PG Bug reporting form <noreply@postgresql.org>)
Список pgsql-bugs
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



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: [16] ALTER SUBSCRIPTION ... SET (run_as_owner = ...) is a no-op
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #18103: bugs of concurrent merge into when use different join plan