From: | Marko Tiikkaja <marko(at)joh(dot)to> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Joel Jacobson <joel(at)trustly(dot)com> |
Cc: | Kevin Grittner <kgrittn(at)ymail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/pgSQL 2 |
Date: | 2014-09-02 17:16:54 |
Message-ID: | 5405FB86.3060006@joh.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/2/14 6:31 PM, Heikki Linnakangas wrote:
> On 09/02/2014 07:12 PM, Joel Jacobson wrote:
>> For me, updating a row, is like setting a variable in a normal language.
>> No normal language would require two rows to set a variable.
>> It would be like having to do:
>> my $var = 10;
>> die unless $var == 10;
>> in Perl to set a variable.
>
> I don't think most applications are like that. See Kevin's comments
> about doing things in a set-oriented way instead of row-by-row. I know
> I've changed several procedures from the row-oriented style, looping
> over rows with a FOR loop, updating each one individually, to
> set-oriented style with a single UPDATE for a bunch of rows. It makes
> for more concise code, and performs better. I'm sure there are
> counter-examples, and I've also written many UPDATE statements that are
> expected to update exactly one row, but I find an ASSERT would be
> adequate for that.
Well, just off the top of my head a normal function invocation could be:
one worker working on a single "order" started by a single end user to
transfer money from one account to another. And we have *a lot* of code
like this where there isn't a way to write the code in "set-oriented
style" without inventing a time machine. Which just might be out of the
scope of plpgsql2 (or perhaps as a GUC).
.marko
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2014-09-02 17:33:25 | Re: PL/pgSQL 2 |
Previous Message | Joel Jacobson | 2014-09-02 17:06:02 | Re: PL/pgSQL 2 |