On Wednesday 11 September 2002 06:11 pm, Stephan Szabo wrote: > On Wed, 11 Sep 2002, snpe wrote: > > On Wednesday 11 September 2002 02:55 pm, Stephan Szabo wrote: > > > On Wed, 11 Sep 2002, snpe wrote: > > > > If decision (transaction or not) is after parser (before execute) > > > > this isn't problem. > > > > I don't know when postgresql make decision, but that is best after > > > > parser. I parser find error simple return error and nothing happen > > > > > > Are you saying that it's okay for: > > > insert into nonexistant values (3); > > > and > > > insert into existant values (3); > > > where 3 is invalid for existant to work > > > differently? > > > I think that'd be tough to get past some people, but you might > > > want to write a proposal for why it should act that way. (Don't > > > expect anything for 7.3, but 7.4's devel will start sometime.) > > > > I don't understand all, but when I tell 'error' I think "syntax error" > > If error is contraint error again nothin change, only error return > > I don't understand what you mean here. Are you saying that both of > those queries should not start transactions? Then that wouldn't > be starting between the parser and execute since you won't know that > the row violates a constraint until execution time. > > > > > > I disagree because I think that two serializable select statements > > > > > in autocommit=off (without a commit or rollback of course) should > > > > > see the same snapshot. > > > > > > > > Question ? > > > > All select in one transaction return same data - no matter if any > > > > change and commit data ? > > > > > > It depends on the isolation level of the transaction I believe. > > > This sequence in read committed (in postgresql) and serializable give > > > different results. > > > > > > T1: begin; > > > T1: select * from a; > > > T2: begin; > > > T2: insert into a values (3); > > > T2: commit; > > > T1: select * from a; > > > > > > In serializable mode, you can't get "non-repeatable read" effects: > > > SQL-transaction T1 reads a row. SQL-transaction T2 then modifies > > > or deletes that row and performs a COMMIT. If T1 then attempts to > > > reread the row, it may receive the modified value of discover that the > > > row has been deleted. > > > > If serialization strict connect with transaction then ok. > > I again am not sure I understand, are you saying that under serializable > select should start a transaction but it shouldn't under read committed? > That seems like a bad idea to me, either it should or it shouldn't in > my opinion. > > Perhaps it'd be better if you wrote up what you think it should do in > all these cases and then we could look at them as a whole. > (Cases I can see right now are, select under serializable, select under > read committed, garbage command, select to non existant table, > insert to non existant table, insert that fails due to unique constraint, > insert that fails due to exception raised by a before trigger, > insert that fails due to exception raised by an after trigger, > insert that does nothing due to before trigger, update that fails > due to any of those after some rows have already successfully been > modified and probably some others).
One question first ? What mean ? ERROR: current transaction is aborted, queries ignored until end of transaction block I am tried next (autocommit=true in postgresql.conf) 1. begin; 2. select * from tab; query work 3. show t; -- force stupid syntax error 4. select * from tab; ERROR: current transaction is aborted, queries ignored until end of transaction block 5.end; 6. select * from tab; query work I must rollback or commit transaction when I make stupid syntax error. This is same with autocommit=false It is maybe ok, I don't know. For rest is ok (if level serializable select start transaction) Thanks ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]