Re: PL/pgSQL 2
| От | Pavel Stehule |
|---|---|
| Тема | Re: PL/pgSQL 2 |
| Дата | |
| Msg-id | CAFj8pRAgpr_ZX49mqMMtpj-EgdQNWxcPnqMb_stMiOtdmmizeA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: PL/pgSQL 2 (Bruce Momjian <bruce@momjian.us>) |
| Список | 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 по дате отправления: