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

On Tue, Jun 19, 2012 at 6:19 PM, Edson Richter <edsonrichter@hotmail.com> 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.