On 1/22/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> i think so...Martijn said it best: you can 'rollback' to, but you
> can't 'commit' to. The 'commit to' would be the arguably much more
> useful way of disposing of a savepoint. But that should be taken up
> with sql standards committee :(.
Merlin Moncure wrote:
> On 1/22/07, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> >one for each INSERT+UPDATE block. This way eiher both of them succeed
> >or fail, within one transaction.
>
> i think so...Martijn said it best: you can 'rollback' to, but you
> can't 'commit' to. The 'commit to' w
On 1/22/07, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
On 1/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > The short version is I would like the ability to run some sql commands
> > and recover the transaction if an error occurs.
>
> I'm getting tired of repeating this, but: neither of you have sa
On 1/22/07, Martijn van Oosterhout wrote:
I don't understand this either. Everything you can do with nested
transactions you can also do with savepoints, so I'm really not
understand what the limitations are?
Actually, looking at the savepoint documentation, it looks like there
is no way to say
On 1/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> The short version is I would like the ability to run some sql commands
> and recover the transaction if an error occurs.
I'm getting tired of repeating this, but: neither of you have said
anything that doesn't appear to me to be handled by ON_ERR
On Mon, Jan 22, 2007 at 11:21:12AM -0500, Merlin Moncure wrote:
> >\begin_nest
> >\commit_nest
> >\rollback_nest
>
> That would work if we could rollback conditionally on failure (like
> on_error_rollback but with definable beginning and ending points). I
Sorry, "rollback conditionally on failur
On 1/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
I'm getting tired of repeating this, but: neither of you have said
anything that doesn't appear to me to be handled by ON_ERROR_ROLLBACK.
What exactly is lacking in that feature?
* the ability to span the savepoint across multiple statements.
* th
On Mon, 2007-01-22 at 16:11 +, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > BEGIN;
> > stmt1;
> > stmt2; <-- error
> > stmt3;
> > COMMIT;
> >
> > results in stmt3 completing successfully even though stmt1 and stmt2 do
> > not == broken script.
>
> stmt1 would still b
On 1/22/07, Martijn van Oosterhout wrote:
we're talking about psql, maybe all we need to do is create the
commands in psql:
\begin_nest
\commit_nest
\rollback_nest
That would work if we could rollback conditionally on failure (like
on_error_rollback but with definable beginning and ending poi
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> BEGIN;
> stmt1;
> stmt2; <-- error
> stmt3;
> COMMIT;
>
> results in stmt3 completing successfully even though stmt1 and stmt2 do
> not == broken script.
stmt1 would still be completed successfully.
--
Gregory Stark
EnterpriseDB http://ww
On Mon, 2007-01-22 at 10:46 -0500, Tom Lane wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > On 1/22/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> >> Could you post an example, just so we're all clear what the problems
> >> are? I thought I understood what you are requesting; I may not.
>
On Mon, Jan 22, 2007 at 10:40:37AM -0500, Merlin Moncure wrote:
> The short version is I would like the ability to run some sql commands
> any error updating foo or bar will blow up the whole thing. Maybe
> this is desirable, but it is often nice to be able to do some error
> handling here. In
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On 1/22/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> Could you post an example, just so we're all clear what the problems
>> are? I thought I understood what you are requesting; I may not.
> ok,
> The short version is I would like the ability to run
On 1/22/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
Could you post an example, just so we're all clear what the problems
are? I thought I understood what you are requesting; I may not.
ok,
The short version is I would like the ability to run some sql commands
and recover the transaction if an e
On Mon, 2007-01-22 at 09:25 -0500, Merlin Moncure wrote:
> On 1/21/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Jaime Casanova" <[EMAIL PROTECTED]> writes:
> > > On 1/21/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > >> - continue on error i.e. COMMIT can/might succeed - though there are
> > >> sti
On 1/22/07, Csaba Nagy <[EMAIL PROTECTED]> wrote:
On Sat, 2007-01-20 at 18:08, Merlin Moncure wrote:
[snip]
> To be honest, I'm not a huge fan of psql tricks (error recovery being
> another example) but this could provide a solution. in your opnion,
> how would you use \if to query the transact
On 1/21/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> On 1/21/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> - continue on error i.e. COMMIT can/might succeed - though there are
>> still cases where it cannot, such as a serializable exception.
> and what s
On Sat, 2007-01-20 at 18:08, Merlin Moncure wrote:
[snip]
> To be honest, I'm not a huge fan of psql tricks (error recovery being
> another example) but this could provide a solution. in your opnion,
> how would you use \if to query the transaction state?
Wouldn't it make sense to introduce inst
On Sun, 2007-01-21 at 13:28 -0500, Tom Lane wrote:
> "Jaime Casanova" <[EMAIL PROTECTED]> writes:
> > On 1/21/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> >> - continue on error i.e. COMMIT can/might succeed - though there are
> >> still cases where it cannot, such as a serializable exception.
>
>
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> At a minimum we need to stop forcing a rollback just because we have a
> syntax error. It makes development a complete pain in the butt and is
> one of the most, "WTF" looks I get when I am training.
> postgres=# begin;
> BEGIN
> postgres=# create ta
> I'd like to see a TODO item to allow an *option* to be set to choose
> between these two transactional behaviours.
> - abort on error
> - continue on error i.e. COMMIT can/might succeed - though there are
> still cases where it cannot, such as a serializable exception.
>
> That's a major change
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> On 1/21/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> - continue on error i.e. COMMIT can/might succeed - though there are
>> still cases where it cannot, such as a serializable exception.
> and what should be the behaviour of that? the same as rollba
On 1/21/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Fri, 2007-01-19 at 15:12 -0500, Merlin Moncure wrote:
> The missing piece of the puzzle is the ability to recover a failed
> transaction without issuing a full commit/rollback.
Agreed.
I'd like to see a TODO item to allow an *option* to be
On Fri, 2007-01-19 at 15:12 -0500, Merlin Moncure wrote:
> The missing piece of the puzzle is the ability to recover a failed
> transaction without issuing a full commit/rollback.
Agreed.
AFAIK all other RDBMS interpret the SQL Standard to mean that a
statement can fail with an ERROR, then furt
On 1/19/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I suspect the savepoint command is almost never used
> outside of oracle compatibility efforts.
Last I heard, we implemented it because it is in the SQL standard.
I have no idea (nor do I much care) wh
Merlin Moncure skrev:
The missing piece of the puzzle is the ability to recover a failed
transaction without issuing a full commit/rollback. This could be a
new flavor of the savepoint command, commit command, or a new command.
As a bonus, upon recovering the transaction you could snap an sql
s
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I suspect the savepoint command is almost never used
> outside of oracle compatibility efforts.
Last I heard, we implemented it because it is in the SQL standard.
I have no idea (nor do I much care) whether it's oracle-compatible.
> BEGIN;
> SAVEPOIN
I've never really been very happy with the decision early on in the
development of nested transactions to use savepoints in the way they
were implemented in the command structure. Savepoints are nearly
useless for sql scripting because there is no way to probe a
transaction and handle error condi
28 matches
Mail list logo
