Re: Feature discussion: Should syntax errors abort a transaction?
От | Scott Marlowe |
---|---|
Тема | Re: Feature discussion: Should syntax errors abort a transaction? |
Дата | |
Msg-id | CAOR=d=22LQfSWaSkajzgyjGnn+FokuOtbt_yA1gVo9sxGQjsiQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Feature discussion: Should syntax errors abort a transaction? (Edson Richter <edsonrichter@hotmail.com>) |
Ответы |
Re: Feature discussion: Should syntax errors abort a transaction?
|
Список | pgsql-general |
But that data was supposed to get transferred into another table first! Data shouldn't just disappear like that. If you want that kind of behaviour use a different db that likes to throw your data away when it shouldn't. On Tue, Jun 19, 2012 at 1:09 PM, Edson Richter <edsonrichter@hotmail.com> wrote: > And I will be pleased that data is gone! I really did not expect anything but this. > If I need such tolerant behavior, then this shall be a feature of my special app, not a feature of the database... If thedeveloper does not know how to write sql, then is time to learn. If the problem is the dynamic generated Sql, then I mustwrite more test cases to cover these new scenarios. But IMHO, database must fail always (syntax or not...). > > Regards, > > Edson > > Scott Marlowe <scott.marlowe@gmail.com> escreveu: > >>On Tue, Jun 19, 2012 at 8:50 AM, Edson Richter <edsonrichter@hotmail.com> wrote: >>> There is also the case of dynamically generated sql statements based on user selection... being syntax or not, I wouldnever want half job done. Thia is the purpose of transactions: or all or nothing... >> >>This this this, and again, this. Imagine: >> >>begin; >>insert into tableb selcet * from tableb; >>truncate tableb; >>commit; >> >>What should happen when we get to the error on the second line? Keep >>going? Boom, data gone because of a syntax error. >> -- To understand recursion, one must first understand recursion.
В списке pgsql-general по дате отправления: