On Mon, Sep 4, 2017 at 11:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I don't want to go there, and was thinking we should expand the new > comment in DefineSavepoint to explain why not.
Okay. > It's certainly not that > much additional work to allow a savepoint so far as xact.c is concerned, > as your patch shows. The problem is that intra-string savepoints seem > inconsistent with exec_simple_query's behavior of abandoning the whole > query string upon error. If you do > > insert ...\; savepoint\; insert ...\; release savepoint\; insert ...; > > wouldn't you sort of expect that the savepoint commands mean to keep going > if the second insert fails? If they don't mean that, what do they mean? Hmm. I spent more time looking at my patch and I see what you are pointing out here. Using something like that with a second insert failing I would expect the first insert to be visible, but that's not the case: savepoint rs; insert into exists values (1); savepoint rs2; insert into not_exists values (1); rollback to savepoint rs2; commit;' So this approach makes things inconsistent. > Now admittedly, the same set of issues pops up if one uses an > explicit transaction block in a multi-query string: > > begin\; insert ...\; savepoint\; insert ...\; release savepoint\; insert > ...\; commit; > > If one of the inserts fails, you don't really know which one unless you > were counting command-complete replies (which PQexec doesn't let you do). > But that behavior was there already, we aren't proposing to make it worse. > (I think this approach is also the correct workaround to give those > Oracle-conversion folk: their real problem is failure to convert from > Oracle's implicit-BEGIN behavior to our explicit-BEGIN.) Sure there is this workaround. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers