According to documentation,

"TRUNCATEis 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:

http://www.postgresql.org/docs/9.0/static/sql-truncate.html

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.

Regards,

Edson Richter.


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 <edsonrich...@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 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.marl...@gmail.com> escreveu:

On Tue, Jun 19, 2012 at 8:50 AM, Edson Richter <edsonrich...@hotmail.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.





Reply via email to