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

Em 19/06/2012 22:26, Scott Marlowe escreveu:
> On Tue, Jun 19, 2012 at 6:19 PM, Edson Richter <edsonrichter(at)hotmail(dot)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.
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,