Re: proposal: plpgsql, new check for extra_errors - strict_expr_check - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: plpgsql, new check for extra_errors - strict_expr_check
Date
Msg-id CAFj8pRDyWGAvmKFOGoQZLebigH3QEL2vKMPLBfMZ3uLM0eZUZA@mail.gmail.com
Whole thread Raw
In response to Re: proposal: plpgsql, new check for extra_errors - strict_expr_check  (Marcos Pegoraro <marcos@f10.com.br>)
List pgsql-hackers


ne 16. 6. 2024 v 19:36 odesílatel Marcos Pegoraro <marcos@f10.com.br> napsal:
Em dom., 16 de jun. de 2024 às 12:11, Pavel Stehule <pavel.stehule@gmail.com> escreveu:
I don't follow this idea - when it does not make sense, then why do you use it?  It can be a signal of some issue in your code.

I don't use it, but sometimes it occurs, and there are lots of languages which ignore it, so it would be cool if plpgsql does it too.
 
If you do this, works
set search_path to public;;;

psql allows it, but it is a shell - not a programming language.
 

but if you do the same inside a block, it does not.

It is a different language. I have not too strong an opinion about it - it is hard to say what is the correct design when you should work with a mix of languages like SQL and Ada (PL/pgSQL), and when related standard SQL/PSM is not widely used. Personally, I don't see any nice features that allow it to accept dirty code. I have negative experiences when a language is tolerant.

Regards

Pavel


regards
Marcos

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Bugfix and improvements in multixact.c
Next
From: Pavel Stehule
Date:
Subject: Re: Schema variables - new implementation for Postgres 15