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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: plpgsql, new check for extra_errors - strict_expr_check
Date: 2025-02-07 20:00:53
Message-ID: CAFj8pRADd0bxWS78iZaJG=dpUTic7jqSgcuEyrjzORLqbr5MaQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

I rewrote this patch. Instead of enhancing the main SQL parser, it does
post parser checks of the parse tree.

Now the patch is significantly less invasive (changes are just in plpgsql -
mostly in grammar), and it is smaller (without regress tests it has half
size).

This patch allows the detection of usage of undocumented syntax for plpgsql
expressions. Using this undocumented
syntax can be the reason why badly written code (missing semicolon) can be
quietly executed without any raising of error.

Only patch 01 is important - patches 02, 03 are prepared for review.
Patch 02 activates a new check by default, and fixes the regress test to be
executed. This is important for checking for possible false alarms.
Patch 03 disables this check and returns regress tests to their original
state.

Regards

Pavel

Attachment Content-Type Size
v20250207-0002-simply-check-of-strict-expr-check-on-regress-test.patch text/x-patch 17.1 KB
v20250207-0003-set-plpgsql.extra_errors-to-none.patch text/x-patch 16.9 KB
v20250207-0001-use-strict-rules-for-parsing-PL-pgSQL-expressions.patch text/x-patch 17.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2025-02-07 20:09:00 Re: should we have a fast-path planning for OLTP starjoins?
Previous Message Matheus Alcantara 2025-02-07 19:59:48 Re: explain analyze rows=%.0f