Re: Feature discussion: Should syntax errors abort a transaction?

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(at)hotmail(dot)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 the developer does not know how to write sql, then is time to learn. If the problem is the dynamic generated Sql, then I must write more test cases to cover these new scenarios. But IMHO, database must fail always (syntax or not...).
>
> Regards,
>
> Edson
>
> Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> escreveu:
>
>>On Tue, Jun 19, 2012 at 8:50 AM, Edson Richter <edsonrichter(at)hotmail(dot)com> wrote:
>>> There is also the case of dynamically generated sql statements based on user selection... being syntax or not, I would never 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.