Re: [HACKERS] plpgsql - additional extra checks - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] plpgsql - additional extra checks
Date
Msg-id CAFj8pRAFoH5Ec30jUpOdaqs_8MEq4-5ah8dOhoVhHx3W2hpqxA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] plpgsql - additional extra checks  (Marko Tiikkaja <marko@joh.to>)
List pgsql-hackers


2017-01-11 15:08 GMT+01:00 Marko Tiikkaja <marko@joh.to>:
On Wed, Jan 11, 2017 at 2:54 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
1. strict_multi_assignment - checks the number of target variables and source values.

I've proposed this before (maybe around a year ago), except the checks were done at parse time, rather than runtime.  I much prefer that approach.  If I recall correctly, the patch was considered to be good, but not good enough since it didn't handle all contexts (perhaps FOR loop were missing, or something; I forget).

Please, can me send a link? Compile time check is better - but I am not sure how much increase a complexity of patch. There should not be necessary data in compile time available. You need a rewriten query - and it is not available in compile time. More in compile time you should not to check dynamic SQL. 
 
 
2. too_many_rows - checks if returned rows is more than one

I've also proposed this, and it was rejected because it was a runtime check, and some people don't like runtime checks.

This runtime check is well controlled, and should be simply enabled, simply disabled - more it is almost impossible process this check in compile time.

Regards

Pavel
 



.m

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] pageinspect: Hash index support
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] pg_restore accepts -j -1