There is a current discussion off-list about what should happen when a
COMMIT is issued for a transaction that cannot be committed for whatever
reason. PostgreSQL returns ROLLBACK as command tag but otherwise succeeds.
Here is an excerpt of Section 17.7 <commit statement> that I feel is
relevant:
<>
6) Case:
a) If any enforced constraint is not satisfied, then any changes to
SQL-data or schemas that were made by the current SQL-transaction are
canceled and an exception condition is raised: transaction rollback —
integrity constraint violation.
b) If any other error preventing commitment of the SQL-transaction has
occurred, then any changes to SQL-data or schemas that were made by the
current SQL-transaction are canceled and an exception condition is
raised: transaction rollback with an implementation-defined subclass value.
c) Otherwise, any changes to SQL-data or schemas that were made by the
current SQL-transaction are eligible to be perceived by all concurrent
and subsequent SQL-transactions.
</>
It seems like this:
postgres=# \set VERBOSITY verbose
postgres=# begin;
BEGIN
postgres=*# error;
ERROR: 42601: syntax error at or near "error"
LINE 1: error;
^
LOCATION: scanner_yyerror, scan.l:1150
postgres=!# commit;
ROLLBACK
should actually produce something like this:
postgres=!# commit;
ERROR: 40P00: transaction cannot be committed
DETAIL: First error was "42601: syntax error at or near "error""
Is this reading correct?
If so, is this something we should fix?
--
Vik Fearing
