Greg Sabino Mullane wrote:
Michael Paesold wrote:2) Implement a server-side function to get the savepoints from the server and query that before every release.
I could not find a way to do this. Is there any interface to the list?
Alvaro suggested to implement such a function. It is not there yet. I think you would have to access the sub xact stack, but I have not looked into that code for quite some time.
http://archives.postgresql.org/pgsql-general/2004-10/msg00370.php
First, I'm not of the opinion that it should automatically be turned off
when running non-interactively. That's too much assuming of what the user
wants, when this is a settable flag. However, it should be settable via
a script to a definite state. So \reseterror will take an optional argument,
"off" or "on", which sets it rather than toggles it.
Discussion here last year showed some concern from people that this feature could bite people and is not really safe. Perhaps the best way would be to create three states:
\reseterrors (on|off|auto)
where auto means it's only active for interactive queries.
(auto could be named interactive)
The other problem is not stepping on other people's savepoints. The best
solution we came up with was to check for savepoint commands ourselves,
similar to the way psql already checks for transaction affecting commands,
and handle things appropriately. Specifically, if someone issues a savepoint
while in \reseterror mode, it switches off automatically*. Since the
implementation of reseterror is pretty much a lazy shortcut to issuing savepoints
yourself, it should be safe to say that you do not want to mix manual and
automatic ones, and we'll back off (with a message) if you issue your own.
Plus there will be a warning in the docs to be careful about mixing savepoints
and the \reseterror method.
* We could also switch it back on after rollback or release, but this would
entail a little more tracking.
Comments?
I would prefer a solution, where the feature is not disabled as soon as I use my own savepoints. I like \reseterror because it prevents making typos from aborting my transaction. Explicit savepoints I rather use to try a whole bunch of statements and then decide if I want to commit so far. I can still make typos.
If you don't want to, I can implement such a savepoint stack. I don't think it's that hard. The parsing, as you mentioned, should also not be too hard, because the infrastructure (removing white space) is already there.
Best Regards,
Michael Paesold
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
