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
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 |