On 9/2/14 5:08 PM, Kevin Grittner wrote:
> Marko Tiikkaja <marko@joh.to> wrote:
>> On 9/2/14 4:26 PM, Kevin Grittner wrote:
>>> Joel Jacobson <joel@trustly.com> wrote:
>>>> The common use-case I have in mind is when you have a function
>>>> which takes some kind of ID as an input param, which maps to a
>>>> primary key in some table, which you want to update.
>>>
>>> In that case FOUND works just fine. A primary key value can't have
>>> more than one matching row.
>>
>> No, but your code can have a bug.
>
> So the main use case is to allow buggy functions which are deployed
> to production without adequate testing to be detected? Bugs like
> not getting the primary key column(s) right?
The main use case is making it more clear *during testing* that the code
is broken. It doesn't hurt that it would also not trash your data if
someone deployed bad code into production, but I think it's more
important to have good tools for testing your code.
> I think it would be
> great to have some way to generate an error if a given statement
> doesn't affect exactly one row, but the above is a pretty weak
> argument for making it a default behavior.
Perhaps.
.marko
