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

From Marko Tiikkaja
Subject Re: PL/pgSQL 2
Date
Msg-id 5405CCED.5060606@joh.to
Whole thread Raw
In response to Re: PL/pgSQL 2  (Joel Jacobson <joel@trustly.com>)
Responses Re: PL/pgSQL 2
Re: PL/pgSQL 2
Re: PL/pgSQL 2
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: PL/pgSQL 2
Next
From: David Johnston
Date:
Subject: [PATCH] Docs 18.1.1 to 18.1.4 - Server Configuration (Settings) Re-Org