On 09/05/2014 10:32 PM, Marko Tiikkaja wrote:
On 2014-09-02 8:52 PM, Kevin Grittner wrote:
Marko Tiikkaja <ma...@joh.to> wrote:
Sounds like in this case you'd only use set-oriented programming
at the end of the transaction, no?
I guess -- more properly I would say "in the final database
transaction for that financial transaction."
Yes, I should have said "financial transaction", but I hit send a bit
too early.
And no, that never
made me wish that plpgsql functions defaulted to throwing errors
for DML statements that affected more than one row.
Fine. But you should still be able to see the point we're trying to
make. The number one is special, and it's present everywhere. If you
want to program defensively, you have to go through a lot of pain right
now. We're looking for a way to alleviate that pain. Defaulting to
throwing errors would be one way to do it, but that's not what's being
suggested here anymore.
You can dismiss what we're doing by saying that it doesn't follow the
best practices or we just want an interface for a key-value store or
whatever. And yes, to some extent, a simple interface for a key-value
store would come in handy. But we still have the 5-15% (big part of it
being the reporting we need to do) of the code that *doesn't* want that,
*and* we want to use all of the Postgres features where applicable.
The point isn't about best practices. The point is that if you want to
ensure that at maximum one row is affected, then qualify it by a unique
set of columns. Making PL/pgSQL behave different on UPDATE than SQL to
enforce that by default was simply a misguided design idea.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
