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.
> 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
> "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:
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
> while in \reseterror mode, it switches off automatically*. Since the
> implementation of reseterror is pretty much a lazy shortcut to issuing
> 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
> and the \reseterror method.
> * We could also switch it back on after rollback or release, but this
> entail a little more tracking.
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.
In response to
pgsql-hackers by date
|Next:||From: Stephen Frost||Date: 2005-01-29 14:14:38|
|Subject: Re: [pgsql-hackers] Allow GRANT/REVOKE permissions to be applied to all schema|
|Previous:||From: Victor Y. Yegorov||Date: 2005-01-29 11:56:12|
|Subject: Implementing Bitmap Indexes|
pgsql-patches by date
|Next:||From: Alvaro Herrera||Date: 2005-01-30 02:47:59|
|Subject: Re: Continue transactions after errors in psql|
|Previous:||From: Tom Lane||Date: 2005-01-29 04:37:51|
|Subject: Re: more fixes for making contrib null safe |