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  (Joel Jacobson <joel@trustly.com>)
Re: PL/pgSQL 2  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: PL/pgSQL 2  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: PL/pgSQL 2
Следующее
От: David Johnston
Дата:
Сообщение: [PATCH] Docs 18.1.1 to 18.1.4 - Server Configuration (Settings) Re-Org