> > > > It starts a transaction, failes the first command and goes into the
> > > > error has occurred in this transaction state. Seems like reasonable
> > > > behavior.
> > >
> > > Select command don't start transaction - it is not good
> >
> > I think you need more justification than "it is not good." If I do a
> > sequence of select statements in autocommit=false, I'd expect the same
> > consistancy as if I'd done
> > begin;
> > select ...;
> > select ...;
> >
> Ok.You start transaction explicit and this is ok.
> But simple SELECT don't start transaction.
Actually someone post a bit from Date's book that implies it does.
And, that's still not an justification, it's just a restating of same
position. I don't see any reason why the two should be different from
a data consistency standpoint, there might be one, but you haven't
given any reasons.
> > > Error command don't start transaction - nothing hapen, only typing error
> >
> > If you do an insert that violates a constraint, does that start an
> > transaction or not? I think we have to choose before we start doing the
> > statement not after.
> This is typeing error.Nothing happen.That is not transaction.
> I don't know that is possible, but before start transaction we need parsing
> command and select or any error don't start transaction
Why not? AFAICT it should, the transaction is initiated a statement is
run and it fails. Now maybe we shouldn't be going into the wierd disabled
statement state, but that's a different argument entirely.
