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
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;
COMMIT;
at the
32 matches
Mail list logo
