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.
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
