Em 19/06/2012 22:26, Scott Marlowe escreveu:
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.
AFAIK, psql open one connection to database - and the transaction is
connection related (two different connections does not share a
transaction). I really mean AFAIK. At this point, someone else with more
internals knowledge can give some light here.
My argument was pro "syntax error should rollback" to make things
safe... :-). Assuming psql is working with only one connection, even in
interactive mode, the transaction should remains valid.
Regards,
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
