Tom Lane wrote: > "Michael Paesold" <[EMAIL PROTECTED]> writes: > > On the other hand, the scenario of a psql option (read: I have > > given up the idea of a backend implementation) to rollback only > > last statement on error is quite different. > > Sure (and we already have one for autocommit). But I thought you were > asking about a backend implementation.
I have implemented what I have suggested for psql. I have attached a first patch for review here, because I have a few questions. Also I want to make sure the whole thing is reasonable. I have named the option "IMPLICIT_SAVEPOINTS", because that's what it is. If someone has a better name that would describe the purpose of the feature, I am happy to change it. The feature is activated, if * \set IMPLICIT_SAVEPOINTS 'on' * connection is in "idle in transaction" state * psql session is interactive The code executes an implicit "SAVEPOINT pg_internal_psql" in common.c/SendQuery to which it will try to rollback to, if the executed query fails. Open questions: * Should psql print a notice in the case of that rollback? Something like "Rollback of last statement successful."? * What is currently missing, is a detection of \i ... obviously this feature should not be used for each query in \i. Perhaps only for the whole \i command? So what should I do to detect \i? Add an extra argument to MainLoop, SendQuery and process_file()? (many changes) Add a global variable in common.c/h (e.g. bool deactivate_implicit_savepoints) that can be used in process_file to temporarily deactivate the code path? (more local changes, but rather a hack imho) Please have a look at the patch and comment. Best Regards, Michael Paesold
implicit_savepoints.patch
Description: Binary data
---------------------------(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
