Re: PL/pgSQL 2
От | Marko Tiikkaja |
---|---|
Тема | Re: PL/pgSQL 2 |
Дата | |
Msg-id | 5405E334.9010205@joh.to обсуждение исходный текст |
Ответ на | Re: PL/pgSQL 2 (Kevin Grittner <kgrittn@ymail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: