Re: PL/pgSQL 2 - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: PL/pgSQL 2
Date
Msg-id CAFj8pRAgpr_ZX49mqMMtpj-EgdQNWxcPnqMb_stMiOtdmmizeA@mail.gmail.com
Whole thread Raw
In response to Re: PL/pgSQL 2  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers



2014-09-03 17:05 GMT+02:00 Bruce Momjian <bruce@momjian.us>:
On Wed, Sep  3, 2014 at 07:54:09AM +0200, Pavel Stehule wrote:
> I am not against to improve a PL/pgSQL. And I repeat, what can be done and can
> be done early:
>
> a) ASSERT clause -- with some other modification to allow better static analyze
> of DML statements, and enforces checks in runtime.
>
> b) #option or PRAGMA clause with GUC with function scope that enforce check on
> processed rows after any DML statement

these two yes
 
>
> c) maybe introduction automatic variable ROW_COUNT as shortcut for GET
> DIAGNOSTICS rc = ROW_COUNT

this is my fresh

some smarty designed asserts can be used for static analyses too.

I am able to analyze plan of DML statements, and I can raise warning if expected rows is not 1 or if there are not filter over unique index

some

UPDATE ... WHERE id = 1;
ASSERT(PROCESSED_ROW_COUNT = 1);

And I can recheck in plpgsql_check, and it can enforce fast check in runtime

Pavel


 

All these ideas are being captured somewhere, right?  Where?

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: PL/pgSQL 2
Next
From: Robert Haas
Date:
Subject: Re: RLS Design