Re: proposal: plpgsql, new check for extra_errors - strict_expr_check

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: plpgsql, new check for extra_errors - strict_expr_check
Date: 2024-06-16 14:36:33
Message-ID: CAFj8pRBTcnj0WBMqwpn_6=aWsbm8GJfBovkx4qL0BTwTzMMe6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

ne 16. 6. 2024 v 16:22 odesílatel Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>
napsal:

> Can you remove or just ignore double ; too ?
>

I don't know - it is a different issue.

PLpgSQL allows zero statements inside block, so you can write BEGIN END or
IF 1 THEN END IF but it doesn't allow empty statement

like ;;

probably it just needs one more rule in gram.y - but in this case, I am not
sure if we should support it.

What is the expected benefit? Generally PL/pgSQL has very strict syntax -
and using double semicolons makes no sense.

>
> postgres=# do $$
> declare var_x integer;
> begin
> var_x = 99;;
> delete from x where x = var_x;
> end; $$;
> ERROR: syntax error at or near ";"
> LINE 1: do $$ declare var_x integer; begin var_x = 99;; delete from ...
>
> Atenciosamente,
>
>
>
>
> Em dom., 16 de jun. de 2024 às 11:12, Pavel Stehule <
> pavel(dot)stehule(at)gmail(dot)com> escreveu:
>
>> Hi,
>>
>> assigned patch try to solve issue reported by Mor Lehr (Missing semicolon
>> in anonymous plpgsql block does not raise syntax error).
>>
>>
>> https://www.postgresql.org/message-id/CALyvM2bp_CXMH_Gyq87pmHJRuZDEhV40u9VP8rX=CAnEt2wUXg@mail.gmail.com
>>
>> by introducing a new extra error check. With this check only a_expr exprs
>> are allowed as plpgsql expressions. This is a small step to behaviour
>> described in SQL/PSM standard (although the language is different, the
>> expression syntax and features are almost similar. With this check the
>> undocumented (but supported syntax)
>>
>> var := column FROM tab
>>
>> is disallowed. Only ANSI syntax for embedded queries (inside assignment
>> statement) is allowed
>>
>> var := (SELECT column FROM tab);
>>
>> With this check, the reported issue (by Mor Lehr) is detected
>>
>> default setting
>>
>> 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; $$
>>
>> -- without reaction - just don't work
>>
>> (2024-06-16 16:05:55) postgres=# set plpgsql.extra_errors to
>> 'strict_expr_check';
>> SET
>> (2024-06-16 16:06:43) postgres=# DO $$
>>
>> DECLARE
>> l_cnt int;
>> BEGIN
>> l_cnt := 1
>> DELETE FROM foo3 WHERE id=1;
>> END; $$;
>> ERROR: syntax error at or near "DELETE"
>> LINE 11: DELETE FROM foo3 WHERE id=1;
>> ^
>>
>> This patch has three parts
>>
>> 1. Introduction strict_expr_check
>> 2. set strict_expr_check as default, and impact on regress tests
>> 3. revert @2
>>
>> I don't propose to be strict_expr_check active by default.
>>
>> Comments, notes?
>>
>> Regards
>>
>> Pavel
>>
>>
>>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marcos Pegoraro 2024-06-16 14:42:51 Re: proposal: plpgsql, new check for extra_errors - strict_expr_check
Previous Message Marcos Pegoraro 2024-06-16 14:22:02 Re: proposal: plpgsql, new check for extra_errors - strict_expr_check