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

From Pavel Stehule
Subject Re: PL/pgSQL 2
Date
Msg-id CAFj8pRDnhXhqFra_CeAi9zSdK0H83AeK-HM_ncsLk0qQ3w5GrA@mail.gmail.com
Whole thread Raw
In response to Re: PL/pgSQL 2  (Marko Tiikkaja <marko@joh.to>)
List pgsql-hackers



2014-09-02 15:58 GMT+02:00 Marko Tiikkaja <marko@joh.to>:
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.

This example is inspiration for me.

one row result can be enforced by some function option.

PERFORM update we don't need, because this code can be moved to other function where one row result will not be enforced.

If I understand to Joel's motivation, he don't need to mix both styles in one function.

one row result can be enforced by function option, function setting or by GUC.

Regards

Pavel
 


.marko

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: PL/pgSQL 2
Next
From: Marko Tiikkaja
Date:
Subject: Re: PL/PgSQL: RAISE and the number of parameters