Re: PL/pgSQL 2

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Joel Jacobson <joel(at)trustly(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/pgSQL 2
Date: 2014-09-02 13:12:59
Message-ID: 1409663579.59999.YahooMailNeo@web122305.mail.ne1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joel Jacobson <joel(at)trustly(dot)com> wrote:

> + Make UPDATE/INSERT/DELETE throw error if they didnt' modify
> exactly 1 row, as that's the most common use-case, and provide
> alternative syntax to modify multiple or zero rows.

I just embarked on wading through the 99 messages (so far) on this
thread, so my apologies if this has already been addressed -- but I
wanted to register a strong objection to making this the default in
any rewrite.  If we want to support a setting or a statement option
for it, fine; but in my personal experience in a production
environment with thousands of plpgsql functions, most functions
written to deal with one row at a time were orders of magnitude
slower than they needed to be -- I spent a lot of my time rewriting
them to use set logic so that they could benefit from the
optimizer's attention.  Getting people to write things in a
declarative style in the first place was difficult because so many
of the programmers were so attached to the imperative style of
coding; making it more difficult for people to Do The Right Thing
is a bad idea IMO.

As a side note, of the many times I rewrote long functions which
looped through individual rows, I would estimate that 80% of them
had subtle bugs which were fixed by changing them to set logic.
Sure, some of those would have caused run-time errors rather than
plausible-but-incorrect results with the change you suggest, but
far from all of them.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

  • PL/pgSQL 2 at 2014-09-01 09:04:53 from Joel Jacobson

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2014-09-02 13:24:24 Re: PL/pgSQL 2
Previous Message Andres Freund 2014-09-02 13:10:14 Re: PL/pgSQL 2