> > > > 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. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
