On 9/2/14 5:08 PM, Kevin Grittner wrote:
Marko Tiikkaja <ma...@joh.to> wrote:
On 9/2/14 4:26 PM, Kevin Grittner wrote:
Joel Jacobson <j...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
