On Sun, Mar 28, 2004 at 10:23:26AM -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > PostgreSQL Bugs List wrote:
> >> In a block transaction, whether or not there were errors in the transaction
> >> issuing a commit; returns a COMMIT confirmation.
>
> > Uh, the tag indicates the COMMIT completed, not that it was a success.
>
> The current philosophy on command tags is "the tag is the same as the
> command actually issued". However we are talking about breaking that
> rule for EXECUTE, and if we do that, it's hard to say that we should
> continue to enforce the rule for COMMIT. It would clearly be useful
> for a COMMIT that ends a failed transaction to report ROLLBACK instead.
>
> > If we throw an error on a COMMIT, people willl think we did not close
> > the transacction,
>
> ... which we wouldn't have. That won't work.
>
> > and if we return a ROLLBACK, they will think they issued a rollback.
>
> Which, in effect, is what they did. Is it likely that this would break
> any clients? The intention of the current design rule is that clients
> can match the tag against the command they issued, but I don't know of
> any client code that actually does that.
>
> In any case, we already have some inconsistencies:
>
> regression=# begin;
> BEGIN
> regression=# end;
> COMMIT
> regression=# begin;
> BEGIN
> regression=# abort;
> ROLLBACK
> regression=#
>
> so it seems that in some cases we're already following a rule more like
> "the tag is the same as the command actually *executed*".
>
> I started out not wanting to make this change either, but the more
> I think about it the harder it is to hold that position.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly
The message could be something like:
COMMIT: Transaction rolled back due to errors
That way, it would reflect both the command and the action.
But I am concerned about the information rather than
the exact message if someone has better ideas.
My reason for submitting the bug was as Tom stated:
> It would clearly be useful
> for a COMMIT that ends a failed transaction to report ROLLBACK instead.
A commit that fails does not commit. It rolls back.
In general, this would make it friendlier for new people and
space cadets that don't notice the last statement failed :-)
Elein
[EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
