2

Recently had a script that failed on Postgres v13 ran but successfully ran on v14. I believe the behaviour in v14 to be strange and potentially a bug, but wanted to check here before submitting a bug report.

  • v13
    • PostgreSQL 13.11 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit
  • v14
    • PostgreSQL 14.6 on aarch64-apple-darwin20.6.0, compiled by Apple clang version 12.0.5 (clang-1205.0.22.9), 64-bit

The offending code was this inside of a function:

RAISE LOG 'Foo %', 'Bar'

DELETE FROM barfoo ...;

Note the missing trailing ; after the RAISE LOG ....

In v13 when trying to run this it raises the error:

ERROR:  syntax error at or near "DELETE"
LINE dd: DELETE FROM barfoo ...;
             ^ 
SQL state: 42601
Character: ddd

Which is the behaviour I would have expected.

When running on v14 there is no raised error, and the code appears to complete normally.

When trying to reproduce this I came up with the following code:

set client_min_messages = 'log';

drop table if exists error_test_tt;
create temp table error_test_tt as (
    select 1 as val
    union
    select 2
);

do $$
begin
    raise log 'test %', '01'
    
    delete from error_test_tt where val = 1;
end
$$;
select * from error_test_tt;

The log test 01 is successfully logged, and the delete ... statement appears to be ignored. The final select * from error_test_tt shows rows with val 1, and 2, meaning nothing was deleted.

Furthermore, the script will fail if the RAISE LOG ... is not using an interpolated value, i.e.:

RAISE LOG 'test 01'

delete from error_test_tt where val = 1;

Reading the documentation, I don't see any reason for this behaviour:
https://www.postgresql.org/docs/14/plpgsql-errors-and-messages.html

Is this a bug?

4
  • 1
    I can reproduce this in Postgres 15, as well. And I doesn't make sense. RAISE takes a variable number of parameters depending on the number of placeholders (%) in the format string. And it supports a variety of syntax variants. Might be a parser bug. Please go ahead an file a bug report. Sep 8, 2023 at 15:04
  • 1
    I'd expect raise log 'test %', '01' to give an error as well - the semicolon is missed , but somehow placeholder + some text + reserved word doesn't give an error . I tried different log levels as well - the same behaviour. raise log 'test %', '01' insert; raise log 'test %', '01' truncate; - go through :-)
    – a1ex07
    Sep 8, 2023 at 23:38
  • Thanks for confirming the issue - have submitted a bug report!
    – Jmase
    Sep 9, 2023 at 2:48
  • This is as designed and documented, see postgr.es/m/2261324.1694292880%40sss.pgh.pa.us . Sep 10, 2023 at 0:57

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.