From: | Jan Wieck <jan(at)wi3ck(dot)info> |
---|---|
To: | Joel Jacobson <joel(at)trustly(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Marko Tiikkaja <marko(at)joh(dot)to>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/pgSQL 2 |
Date: | 2014-09-02 21:23:26 |
Message-ID: | 5406354E.5050208@wi3ck.info |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/02/2014 12:20 PM, Joel Jacobson wrote:
> On Tue, Sep 2, 2014 at 6:09 PM, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
>> Joel Jacobson <joel(at)trustly(dot)com> wrote:
>>
>>> Sorry for being unclear, I didn't mean to suggest the main concern is
>>> updating *all* rows.
>>> The main concern is when you have a rather complex UPDATE WHERE clause,
>>> aiming to update exactly one row. Some of the expressions might be
>>> assertions, to just double-verify the values and to make it stand-out
>>> you are checking those expressions.
>>
>>
>> These are two different problems which probably need two different
>> solutions. Making the default behavior of a set-based command that
>> it throw an error if the resulting set is not exactly one row
>> doesn't seem like the right solution to either one of them.
>
> I see your point.
> Basically, we have two types of applications where PL/pgSQL is commonly used.
> a) OLTP applications where you typically operate on one row for each
> UPDATE command.
Your idea of what an OLTP application is seems flawed.
> b) Data warehouseing applications where you process multiple rows in
> each UPDATE command.
Ditto.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-09-02 21:23:58 | Re: Escaping from blocked send() reprised. |
Previous Message | Joel Jacobson | 2014-09-02 21:21:50 | Re: PL/pgSQL 2 |