From: | Zeugswetter Andreas IZ5 <Andreas(dot)Zeugswetter(at)telecom(dot)at> |
---|---|
To: | PostgreSQL Developers List <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Savepoints... |
Date: | 1999-06-17 06:55:27 |
Message-ID: | 219F68D65015D011A8E000006F8590C60267B39E@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Actually, I think a lot of the cases where rollback to savepoint
would be done implicitly could be avoided by adding a fourth
behavior of elog.
This elog, let's e.g. call it elog(WARN,...) would actually behave
like an elog(NOTICE,..) in the backend, but would return ERROR
to the client. I think at least all elogs that happen in the parser
could be handled like this, and a lot of the others.
Of course the client would need an error code, but that is your
2. item anyway :-)
The following example is IMHO not necessary,
with or without savepoints:
regression=> begin work;
BEGIN
regression=> insert into t2 values (1, 'one');
INSERT 151498 1
regression=> blabla;
ERROR: parser: parse error at or near "blabla"
regression=> commit work; -- actually this is currently a bug,
-- it must ERROR, since only
rollback work
END -- is allowed in txn abort state
regression=> select * from t2;
a|b
-+-
(0 rows)
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Samersoff | 1999-06-17 07:13:27 | Re: UnixWare |
Previous Message | Young-Woo Cho | 1999-06-17 06:30:04 | Could you help me ? |