Re: Missing semicolumn in anonymous plpgsql block does not raise syntax error - Mailing list pgsql-bugs

From Mor Lehr
Subject Re: Missing semicolumn in anonymous plpgsql block does not raise syntax error
Date
Msg-id CALyvM2ZJytKx+HfayNkvdJ3YcfeCkp0nc8H0gL0bYfFNPBF4Yw@mail.gmail.com
Whole thread Raw
In response to Re: Missing semicolumn in anonymous plpgsql block does not raise syntax error  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-bugs
Thanks for the prompt reply.
Can you please refer me to the section in the documentation that describes this behavior?
This (automatically interperting 1 as select 1) is totally an unexpected behavior for me.

Thanks again.
-Mor.


On Sun, Jun 2, 2024, 18:19 David G. Johnston <david.g.johnston@gmail.com> wrote:
On Sunday, June 2, 2024, Mor Lehr <mor.lehr@deel.com> wrote:
Hi,

I would like to report a potential bug in postgres 15.4, also reproduced on 15.6.

The exact sequence of steps:
Connect to a postgres 15.4 database and run the following statements:

CREATE TABLE foo3(id serial PRIMARY key, txt text);

INSERT INTO foo3 (txt) VALUES ('aaa'),('bbb');

DO $$

DECLARE

l_cnt int;

BEGIN

l_cnt := 1

DELETE FROM foo3 WHERE id=1;

END; $$;


The output you got:

1. The script passes (no error message) even though there's a missing semicolon (;) after "l_cnt := 1"
2. The script doesn't actually delete the record from foo3



I think you just wrote the equivalent of:

l_cnt := (select 1 as delete from foo3 where id=1);

Which is a valid query.

David J.


pgsql-bugs by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: BUG #18490: Assert in comparetup_index_btree_tiebreak() fails when pg_class reindexed during a table creation
Next
From: "David G. Johnston"
Date:
Subject: Re: Missing semicolumn in anonymous plpgsql block does not raise syntax error