According to documentation,
"TRUNCATE is transaction-safe with respect to the data in the tables: the truncation will be safely rolled back if the surrounding transaction does not commit."
You will find this description at following page:
So, when you have the "syntax error" on second line, then transaction is rolled back (cannot proceed: and that's why Syntax Errors should be treated as any other error) and your data is safe.
Em 19/06/2012 18:58, Scott Marlowe escreveu:
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@xxxxxxxxxxx> 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.marlowe@xxxxxxxxx> escreveu:On Tue, Jun 19, 2012 at 8:50 AM, Edson Richter <edsonrichter@xxxxxxxxxxx> 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.
[Postgresql Jobs] [Postgresql Admin] [Postgresql Performance] [Linux Clusters] [PHP Home] [PHP on Windows] [Programming PHP] [Kernel Newbies] [PHP Classes] [Find Someone Nice] [PHP Books] [PHP Databases] [Postgresql & PHP] [Yosemite]