Re: PL/pgSQL 2

2014-09-02 15:58 GMT+02:00 Marko Tiikkaja <marko(at)joh(dot)to>:

> On 9/2/14 3:52 PM, Joel Jacobson wrote:
>
>> On Tue, Sep 2, 2014 at 3:41 PM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)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
>