Re: PL/pgSQL 2

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Marko Tiikkaja <marko(at)joh(dot)to>
Cc: Joel Jacobson <joel(at)trustly(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/pgSQL 2
Date: 2014-09-02 09:41:50
Message-ID: CAFj8pRC4dcemmWQSH840sC-eKFu-ADy1M6AuCG=DXz9nOcmRfg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

> On 9/2/14 11:04 AM, Pavel Stehule wrote:
>
>> It is relatively natural and we use similar construct in CONTINUE
>> statement.
>>
>> 2. What can be next? We can implement some idiom (shortcut) for GET
>> DIAGNOSTICS
>>
>> DELETE FROM tab WHERE xx = somevar;
>> RAISE EXCEPTION 'some' WHEN AFFECTED_ROW_COUNT <> 1;
>>
>
> Yes, a special variable would be closer to how I would prefer to access
> the row count.

I am not against. We have FOUND, we can have "AFFECTED_ROW_COUNT" or
something else. "ROW_COUNT" is probably wide used as variable.

This "style" can be simply implemented.

Pavel

>
>
> 3. What next? Maybe some notations -
>>
>> -- ** ensure_exact_one_row
>> DELETE FROM tab WHERE xx = somevar;
>>
>
> I really, really don't like the idea of turning regular SQL statements
> into something slightly different based on comments around (or "inside")
> the query.
>

it can be something else than comment. For me, it is really futuristic, but
it has more potential than using some specialized keywords inside SQL
statement. More, we can mix it with #option - be global for function.

>
>
> .marko
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Hernández Tortosa 2014-09-02 09:44:16 Re: PL/pgSQL 2
Previous Message Álvaro Hernández Tortosa 2014-09-02 09:40:28 Re: PL/pgSQL 2