Re: PL/pgSQL 2
От | Marko Tiikkaja |
---|---|
Тема | Re: PL/pgSQL 2 |
Дата | |
Msg-id | 5405CCED.5060606@joh.to обсуждение исходный текст |
Ответ на | Re: PL/pgSQL 2 (Joel Jacobson <joel@trustly.com>) |
Ответы |
Re: PL/pgSQL 2
Re: PL/pgSQL 2 Re: PL/pgSQL 2 |
Список | pgsql-hackers |
On 9/2/14 3:52 PM, Joel Jacobson wrote: > On Tue, Sep 2, 2014 at 3:41 PM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> On 09/02/2014 04:32 PM, Joel Jacobson wrote: >>> I think it's much better to make it the default behaviour in plpgsql2 >>> than to add a new syntax to plpgsql, >>> because then we don't have to argue what to call the keyword or where to >>> put it. >> >> >> Then you'll have to argue what the *other* syntax should look like. And not >> everyone agrees on the default either, see Kevin's email. Designing a new >> language is going to be an uphill battle, even more so than enhancing >> current plpgsql. > > Any ideas on what the *other* syntax could look like? When I've played around with the idea of fixing PL/PgSQL in my head, what I had in mind is that UPDATE and DELETE not affecting exactly one row raises an exception, unless PERFORM is used. PERFORM would set a special variable (e.g. ROW_COUNT) which can be consulted after the operation. For example: UPDATE foo WHERE bar = 1; -- must affect exactly one row PERFORM UPDATE foo WHERE bar = 1; -- can affect any number of rows IF row_count > 1 THEN RAISE EXCEPTION 'oh no'; END IF; This, obviously, requires us to get rid of the requirement for PERFORM today, which I see as a win as well. .marko
В списке pgsql-hackers по дате отправления: