On Tue, Jun 19, 2012 at 6:19 PM, Edson Richter <edsonrichter@xxxxxxxxxxx> wrote: > 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: > > 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. Yes but the discussion was that the syntax error SHOULDN'T cause a roll back, and I was giving an example of when a transaction should have rolled back but wouldn't have if syntax errors didn't cause rollback. In a different vein, the issue of "interactive" versus "scripted" is something I don't want to take chances on getting wrong. If I'm in the psql terminal and type \i /tmp/somesqlile.sql is that interactive or scripted? How can psql know? Should it know? Can I trust it to make the right decision of interactive versus scripted each time? I generally put more than two lines of sql in a text file, edit it, and throw at begin; on it. run it with \i and then commit or rollback as needed. It documents what you did so you can check it in somewhere, and makes it repeatable. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
