On 09/05/2014 10:32 PM, Marko Tiikkaja wrote:
> On 2014-09-02 8:52 PM, Kevin Grittner wrote:
>> Marko Tiikkaja <marko@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