Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
1 - All SETs are rolled back in aborted transaction
2 - SETs are ignored after transaction abort
3 - All SETs are honored in aborted transaction
? - Have SETs vary in behavior depending on variable
My
Hiroshi Inoue wrote:
I'd be willing to consider making the behavior variable-specific
if anyone can identify particular variables that need to behave
differently. But overall I think it's better that the behavior
be consistent --- so you'll need a good argument to convince me
that
OK, would people please vote on how to handle SET in an aborted
transaction?
at the end, should 'x' equal:
1 - All SETs are rolled back in aborted transaction
2 - SETs are ignored after transaction abort
3 - All SETs are honored in aborted transaction
? -
Thomas Lockhart [EMAIL PROTECTED] writes:
Let me give you some examples. We might someday have nested
transactions, or transactions which can be resumed from the point of
failure. We *might* want to be able to affect recovery behaviors, and we
*might* want to do so with something like
On Wed, 24 Apr 2002, Michael Loftis wrote:
Vote number 1 -- ROLL BACK
I agree.. Number 1 - ROLL BACK
Bruce Momjian wrote:
OK, would people please vote on how to handle SET in an aborted
transaction? This vote will allow us to resolve the issue and move
forward if needed.
In the
Bruce Momjian wrote:
OK, would people please vote on how to handle SET in an aborted
transaction? This vote will allow us to resolve the issue and move
forward if needed.
In the case of:
SET x=1;
BEGIN;
SET x=2;
query_that_aborts_transaction;
Tom Lane wrote:
Right offhand, I am not seeing anything here for which there's a
compelling case not to roll it back on error.
In fact, I have yet to hear *any* plausible example of a variable
that we would really seriously want not to roll back on error.
Honetsly I don't understand
Hiroshi Inoue wrote:
Tom Lane wrote:
Right offhand, I am not seeing anything here for which there's a
compelling case not to roll it back on error.
In fact, I have yet to hear *any* plausible example of a variable
that we would really seriously want not to roll back on error.
Jan Wieck wrote:
Hiroshi Inoue wrote:
Tom Lane wrote:
Right offhand, I am not seeing anything here for which there's a
compelling case not to roll it back on error.
In fact, I have yet to hear *any* plausible example of a variable
that we would really seriously want not to
Hiroshi Inoue [EMAIL PROTECTED] writes:
Honetsly I don't understand what kind of example you
expect. How about the following ?
[The curren schema is schema1]
begin;
create schema foo;
set search_path = foo;
create table t1 ();
.
[error occurs]
Hiroshi Inoue wrote:
What's wrong with it ? The insert command after *rollback*
would fail. It seems the right thing to me. Otherwise
the insert command would try to append the data of the
table t1 to itself. The insert command is for copying
schema1.t1 to foo.t1 in case the previous create
Michael Loftis wrote:
Hiroshi Inoue wrote:
What's wrong with it ? The insert command after *rollback*
would fail. It seems the right thing to me. Otherwise
the insert command would try to append the data of the
table t1 to itself. The insert command is for copying
schema1.t1 to foo.t1 in
Hiroshi Inoue wrote:
Michael Loftis wrote:
Hiroshi Inoue wrote:
What's wrong with it ? The insert command after *rollback*
would fail. It seems the right thing to me. Otherwise
the insert command would try to append the data of the
table t1 to itself. The insert command is for
Hiroshi Inoue wrote:
Michael Loftis wrote:
Hiroshi Inoue wrote:
What's wrong with it ? The insert command after *rollback*
would fail. It seems the right thing to me. Otherwise
the insert command would try to append the data of the
table t1 to itself. The insert command is for copying
Hiroshi Inoue wrote:
Sure should it! You gave an example for the need to roll
back, because
otherwise you would end up with an invalid
search path foo.
What's wrong with it ? The insert command after *rollback*
would fail. It seems the right thing to me.
Bruce Momjian wrote:
Hiroshi, we need a psql solution too. People are feeding query files
into psql all the time and we should have an appropriate behavior for
them.
I now understand your point that from a ODBC perspective, you may not
want SETs rolled back and you would rather ODBC handle
Michael Loftis wrote:
Hiroshi Inoue wrote:
Where's the restriction that all objects in a schema
must be created in an transaction ? Each user has his
reason and would need various kind of command call sequence.
What I've mainly insisted is what to do with errors is
users' responsibilty
Jan Wieck wrote:
Hiroshi Inoue wrote:
Sure should it! You gave an example for the need to roll
back, because
otherwise you would end up with an invalid
search path "foo".
What's wrong with it ? The insert command after *rollback*
would fail. It seems the
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Hiroshi, we need a psql solution too. People are feeding query files
into psql all the time and we should have an appropriate behavior for
them.
What are you expecting for psql e.g. the following
wrong(?) example ?
[The curren schema is
Michael Loftis wrote:
Bruce Momjian wrote:
Hiroshi, we need a psql solution too. People are feeding query files
into psql all the time and we should have an appropriate behavior for
them.
I now understand your point that from a ODBC perspective, you may not
want SETs rolled back and
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Hiroshi, we need a psql solution too. People are feeding query files
into psql all the time and we should have an appropriate behavior for
them.
What are you expecting for psql e.g. the following
wrong(?) example ?
Bruce Momjian wrote:
Hiroshi Inoue wrote:
What are you expecting for psql e.g. the following
wrong(?) example ?
[The curren schema is schema1]
begin;
create schema foo;
set search_path = foo;
create table t1 (); [error occurs]
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
What are you expecting for psql e.g. the following
wrong(?) example ?
[The curren schema is schema1]
begin;
create schema foo;
set search_path = foo;
create table
Bruce Momjian wrote:
What are you expecting for psql e.g. the following
wrong(?) example ?
[The curren schema is schema1]
begin;
create schema foo;
set search_path = foo;
create table t1 (); [error occurs]
* Bruce Momjian ([EMAIL PROTECTED]) [020423 12:30]:
1 - All SETs are rolled back in aborted transaction
2 - SETs are ignored after transaction abort
3 - All SETs are honored in aborted transaction
? - Have SETs vary in behavior depending on variable
Our
Bradley McLean wrote:
* Bruce Momjian ([EMAIL PROTECTED]) [020423 12:30]:
1 - All SETs are rolled back in aborted transaction
2 - SETs are ignored after transaction abort
3 - All SETs are honored in aborted transaction
? - Have SETs vary in behavior depending on
1
SET should follow transaction semantics and rollback.
Jan
Bruce Momjian wrote:
OK, would people please vote on how to handle SET in an aborted
transaction? This vote will allow us to resolve the issue and move
forward if needed.
In the case of:
SET x=1;
Bruce Momjian [EMAIL PROTECTED] writes:
1 - All SETs are rolled back in aborted transaction
2 - SETs are ignored after transaction abort
3 - All SETs are honored in aborted transaction
? - Have SETs vary in behavior depending on variable
My vote is 1 - roll back all
On Tuesday 23 April 2002 04:27 pm, Bruce Momjian wrote:
OK, would people please vote on how to handle SET in an aborted
transaction? This vote will allow us to resolve the issue and move
forward if needed.
at the end, should 'x' equal:
1 - All SETs are rolled back in aborted
Bruce Momjian wrote:
OK, would people please vote on how to handle SET in an aborted
transaction? This vote will allow us to resolve the issue and move
forward if needed.
In the case of:
SET x=1;
BEGIN;
SET x=2;
query_that_aborts_transaction;
SET x=3;
30 matches
Mail list logo
