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
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 = f
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 (); [err
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(?)
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 rol
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 i
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
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' resp
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 han
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
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 fo
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
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
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
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 occ
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 reall
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
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 understan
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
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.
> >
Vote 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 case of:
>
> SET x=1;
> BEGIN;
> SET x=2;
> query_that_abort
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
>
> 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
>
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
> >
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 variabl
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;
>
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 tra
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
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;
>
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 depen
* 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
>
> Ou
31 matches
Mail list logo
