PROTECTED]>
Sent: Monday, April 29, 2002 2:10 PM
Subject: Re: [HACKERS] Vote totals for SET in aborted transaction
LOCAL SET ?
>>
>
> What happens inside of a nested transaction, assuming we do have those
> evenually ... ?
>
> On Mon, 29 Apr 2002, Tom Lane wrote
> I don't really get it. We had a voting and I think I saw a
> clear enough result with #1, transactional behaviour, as the
> winner.Maybe I missed something, but what's this
> disscussion about?
Getting the right solution ;)
There was not a consensus, just a vote, and the *reas
On Mon, 29 Apr 2002, Jan Wieck wrote:
> Marc G. Fournier wrote:
> >
> > What happens inside of a nested transaction, assuming we do have those
> > evenually ... ?
>
> Folks,
>
> I don't really get it. We had a voting and I think I saw a
> clear enough result with #1, transactional beha
Jan Wieck <[EMAIL PROTECTED]> writes:
> I don't really get it. We had a voting and I think I saw a
> clear enough result with #1, transactional behaviour, as the
> winner.Maybe I missed something, but what's this
> disscussion about?
We agreed on transactional beh
Marc G. Fournier wrote:
>
> What happens inside of a nested transaction, assuming we do have those
> evenually ... ?
Folks,
I don't really get it. We had a voting and I think I saw a
clear enough result with #1, transactional behaviour, as the
winner.Maybe I missed some
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> What happens inside of a nested transaction, assuming we do have those
> evenually ... ?
Presumably, an error inside a nested transaction would cause you to
revert back to whatever the SET situation was at start of that
subtransaction.
Offhand thi
On Mon, 29 Apr 2002, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > If we go with your syntax I would prefer SET LOCAL to LOCAL SET , so
> > that LOCAL feels tied more to variable rather than to SET .
>
> I agree. I was originally thinking that that way might require LOCAL to
>
What happens inside of a nested transaction, assuming we do have those
evenually ... ?
On Mon, 29 Apr 2002, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Perhaps we could do
> > SET SET TO LOCAL TO TRANSACTION;
> > Which would affect itself and all subsequent SET commands up t
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Just as a stupid question here ... but, why do we wrap single queries into
> a transaction anyway? IMHO, a transaction is meant to tell the backend to
> remember this sequence of events, so that if it fails, you can roll it
> back ... with a singl
Hannu Krosing <[EMAIL PROTECTED]> writes:
> And I also think that this will solve the original issue, which iirc was
> rolling back SET TIMEOUT at ABORT.
It does provide a way to deal with that problem. But we still have the
example of
begin;
create schema foo;
set searc
Hannu Krosing <[EMAIL PROTECTED]> writes:
> If we go with your syntax I would prefer SET LOCAL to LOCAL SET , so
> that LOCAL feels tied more to variable rather than to SET .
I agree. I was originally thinking that that way might require LOCAL to
become a reserved word, but we should be able to
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> I can certainly think of uses for a local-effects flavor of SET.
>> But I don't want that to be the only flavor.
> Right. And there was no suggestion that there be so; the original
> proposal used "BEGIN/END blocks" to differentiate the usage.
Right
On Mon, 2002-04-29 at 18:20, Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > Rather than dismissing this out of hand, try to look at what it *does*
> > enable. It allows developers to tune specific queries without having to
> > restore values afterwards. Values or settings which
Marc G. Fournier wrote:
> On Mon, 29 Apr 2002, Bruce Momjian wrote:
>
> > Hannu Krosing wrote:
> > > On Mon, 2002-04-29 at 17:09, Scott Marlowe wrote:
> > > > For this reason, I propose that a transaction should "inherit" its
> > > > environment, and that all changes EXCEPT for those affecting tu
On Mon, 2002-04-29 at 17:53, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Perhaps we could do
> > SET SET TO LOCAL TO TRANSACTION;
> > Which would affect itself and all subsequent SET commands up to
> > SET SET TO GLOBAL;
> > or end of transaction.
>
> This makes my head hurt
On Mon, 29 Apr 2002, Bruce Momjian wrote:
> Hannu Krosing wrote:
> > On Mon, 2002-04-29 at 17:09, Scott Marlowe wrote:
> > > For this reason, I propose that a transaction should "inherit" its
> > > environment, and that all changes EXCEPT for those affecting tuples should
> > > be rolled back aft
On Mon, 29 Apr 2002, Tom Lane wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
> > I've been thinking this over and over, and it seems to me, that the way
> > SETS in transactions SHOULD work is that they are all rolled back, period,
> > whether the transaction successfully completes OR NOT.
>
> It's hardly a trivial point, seeing that transactions are such a
> fundamental aspect of the system. The statements that we have now that
> depend on being-in-a-transaction-block-or-not (eg, VACUUM) are ugly
> kluges IMHO.
This is certainly not in the same category. And I'm sure you can see
up
Oh, I like ... kinda like in perl where if you set a variable 'my' inside
of conditional, it no longer exists outside of that conditional ...
I do like this ...
On Mon, 29 Apr 2002, Scott Marlowe wrote:
> I've been thinking this over and over, and it seems to me, that the way
> SETS in transac
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Rather than dismissing this out of hand, try to look at what it *does*
> enable. It allows developers to tune specific queries without having to
> restore values afterwards. Values or settings which may change from
> version to version, so end up embed
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Let's not let trivial english semantics divert the discussion please.
It's hardly a trivial point, seeing that transactions are such a
fundamental aspect of the system. The statements that we have now that
depend on being-in-a-transaction-block-or-no
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Perhaps we could do
> SET SET TO LOCAL TO TRANSACTION;
> Which would affect itself and all subsequent SET commands up to
> SET SET TO GLOBAL;
> or end of transaction.
This makes my head hurt. If I do
SET foo TO bar;
begin;
SE
...
> Agreed, very non-intuitive. And can you imagine how many applications
> we would break.
What is non-intuitive about it? What it *does* do is free the programmer
from worrying about side effects which *do* break applications.
Rather than dismissing this out of hand, try to look at what it
...
> This would make it impossible for SET to have any persistent effect
> at all. (Every SQL command is inside a transaction --- an
> implicitly-established one if necesary, but there is one.)
Of course the behavior would need to be defined from the user's
viewpoint, not from a literal descrip
On Mon, 2002-04-29 at 17:30, Tom Lane wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
> > I've been thinking this over and over, and it seems to me, that the way
> > SETS in transactions SHOULD work is that they are all rolled back, period,
> > whether the transaction successfully completes O
Hannu Krosing wrote:
> On Mon, 2002-04-29 at 17:09, Scott Marlowe wrote:
> > For this reason, I propose that a transaction should "inherit" its
> > environment, and that all changes EXCEPT for those affecting tuples should
> > be rolled back after completion, leaving the environment the way we f
Scott Marlowe <[EMAIL PROTECTED]> writes:
> I've been thinking this over and over, and it seems to me, that the way
> SETS in transactions SHOULD work is that they are all rolled back, period,
> whether the transaction successfully completes OR NOT.
This would make it impossible for SET to have
> I've been thinking this over and over, and it seems to me, that the way
> SETS in transactions SHOULD work is that they are all rolled back, period,
> whether the transaction successfully completes OR NOT.
Very interesting! This is a *consistant* use of SET which allows
transactions to be const
On Mon, 2002-04-29 at 17:09, Scott Marlowe wrote:
> For this reason, I propose that a transaction should "inherit" its
> environment, and that all changes EXCEPT for those affecting tuples should
> be rolled back after completion, leaving the environment the way we found
> it. If you need the
I've been thinking this over and over, and it seems to me, that the way
SETS in transactions SHOULD work is that they are all rolled back, period,
whether the transaction successfully completes OR NOT.
Transactions ensure that either all or none of the DATA in the database is
changed. That na
At 11:50 25/04/02 -0400, Bruce Momjian wrote:
>Marc G. Fournier wrote:
> >
> > Just curious here, but has anyone taken the time to see how others are
> > doing this? For instance, if we go with 1, are going against how everyone
> > else handles it? IMHO, its not a popularity contest ...
Dec/RDB
At 11:49 AM 4/26/02 -0400, Tom Lane wrote:
>I'm still looking for an example of something that is (a) reasonable
>to set on a per-backend basis, and (b) not reasonable to roll back
>if it's set in a transaction that fails.
The way I see it is if (a) and you don't want it rolled back, you could pu
Marc G. Fournier wrote:
> > Second, there is the idea of doing #1, and having a GUC variable for #3.
> > Does anyone want that? I think Marc may. Anyone else?
>
> Actually, in light of Tom's comment about it not being the same syntax, I
> have to admit that I missed that syntax difference in th
On Fri, 26 Apr 2002, Bruce Momjian wrote:
> Tom Lane wrote:
> > Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> > > Coz some things should not be rolled back. So you guys might come up with a
> > > different keyword for it.
> >
> > > CONFIG: for non transactional stuff that can appear as SQL statement
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> I was trying to say that _IF_ one ever needs to "SET" stuff that can't be
> rolled back then it may be better to use some other keyword for that feature.
> I'm actually for #1 SET being rolled back and to not have any "Oracle
> behaviour" settings at al
Bruce Momjian wrote:
> So you do see a difference between SET and DROP TABLE because the second
> is a utility command. OK, I'll buy that, but my point was different.
>
> My point was that we don't match Oracle for DROP TABLE, so why is
> matching for SET so important?
Good point, I never
At 10:34 AM 4/26/02 -0400, Tom Lane wrote:
>Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> > Coz some things should not be rolled back. So you guys might come up
> with a
> > different keyword for it.
>
> > CONFIG: for non transactional stuff that can appear as SQL statements.
> > SET: for stuff that
Jan Wieck <[EMAIL PROTECTED]> writes:
> SET does not. But Bruce said he doesn't see DROP TABLE beeing
> totally different. That is related to xmin/xmax, isn't it?
I think what Bruce meant was "if rollback is good for DROP TABLE,
why isn't it good for SET"?
rega
Tom Lane wrote:
> Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> > Coz some things should not be rolled back. So you guys might come up with a
> > different keyword for it.
>
> > CONFIG: for non transactional stuff that can appear as SQL statements.
> > SET: for stuff that can be transactional.
>
>
Jan Wieck wrote:
> Bruce Momjian wrote:
> > Marc G. Fournier wrote:
> > > On Thu, 25 Apr 2002, Bruce Momjian wrote:
> > >
> > > >
> > > > Marc is suggesting we may want to match Oracle somehow.
> > > >
> > > > I just want to have our SET work on a sane manner.
> > >
> > > Myself, I wonder why Orac
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> Coz some things should not be rolled back. So you guys might come up with a
> different keyword for it.
> CONFIG: for non transactional stuff that can appear as SQL statements.
> SET: for stuff that can be transactional.
People keep suggesting this, an
Marc G. Fournier wrote:
> On Fri, 26 Apr 2002, Jan Wieck wrote:
>
> > Bruce Momjian wrote:
> > > Marc G. Fournier wrote:
> > > > On Thu, 25 Apr 2002, Bruce Momjian wrote:
> > > >
> > > > >
> > > > > Marc is suggesting we may want to match Oracle somehow.
> > > > >
> > > > > I just want to have our
On Fri, 26 Apr 2002, Jan Wieck wrote:
> Bruce Momjian wrote:
> > Marc G. Fournier wrote:
> > > On Thu, 25 Apr 2002, Bruce Momjian wrote:
> > >
> > > >
> > > > Marc is suggesting we may want to match Oracle somehow.
> > > >
> > > > I just want to have our SET work on a sane manner.
> > >
> > > Mys
Curt Sampson wrote:
> On Fri, 26 Apr 2002, Marc G. Fournier wrote:
>
> > NOTE that I *do* think that #1 is what *should* happen, but there should
> > be some way of turning off that behaviour so that we don't screw up ppl
> > expecting "Oracles behaviour" ...
>
> I don't think this follows. If it'
Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Thu, 25 Apr 2002, Bruce Momjian wrote:
> >
> > >
> > > Marc is suggesting we may want to match Oracle somehow.
> > >
> > > I just want to have our SET work on a sane manner.
> >
> > Myself, I wonder why Oracle went the route they went ... does
Marc G. Fournier writes:
> Myself, I wonder why Oracle went the route they went ... does anyone have
> access to a Sybase / Informix system, to confirm how they do it? Is
> Oracle the 'odd man out', or are we going to be that? *Adding* something
> (ie. DROP TABLE rollbacks) that nobody appea
On Fri, 26 Apr 2002, Marc G. Fournier wrote:
> NOTE that I *do* think that #1 is what *should* happen, but there should
> be some way of turning off that behaviour so that we don't screw up ppl
> expecting "Oracles behaviour" ...
I don't think this follows. If it's only for people's expectations
Marc G. Fournier wrote:
> > Yes, let's find out what the others do. I don't see DROP TABLE
> > rollbacking as totally different. How is it different from SET?
>
> SET currently has an "accepted behaviour" with other DBMSs, or, at least,
> with Oracle, and that is to ignore the rollback ...
>
>
At 04:01 PM 4/25/02 -0300, Marc G. Fournier wrote:
> > My guess is that we should implement #1 and see what feedback we get in
> > 7.3.
>
>IMHO, it hasn't been thought out well enough to be implemented yet ... the
>options have been, but which to implement haven't ... right now, #1 is
>proposing t
On Thu, 25 Apr 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Thu, 25 Apr 2002, Bruce Momjian wrote:
> >
> > >
> > > Marc is suggesting we may want to match Oracle somehow.
> > >
> > > I just want to have our SET work on a sane manner.
> >
> > Myself, I wonder why Oracle went the rou
Vince Vielhaber wrote:
> On Thu, 25 Apr 2002, Bruce Momjian wrote:
>
> >
> > Marc is suggesting we may want to match Oracle somehow.
> >
> > I just want to have our SET work on a sane manner.
>
> As do I. But to Marc's suggestion, we discussed an oracle compatibility
> factor in the past and it
Marc G. Fournier wrote:
> On Thu, 25 Apr 2002, Bruce Momjian wrote:
>
> >
> > Marc is suggesting we may want to match Oracle somehow.
> >
> > I just want to have our SET work on a sane manner.
>
> Myself, I wonder why Oracle went the route they went ... does anyone have
> access to a Sybase / In
On Thu, 25 Apr 2002, Bruce Momjian wrote:
>
> Marc is suggesting we may want to match Oracle somehow.
>
> I just want to have our SET work on a sane manner.
Myself, I wonder why Oracle went the route they went ... does anyone have
access to a Sybase / Informix system, to confirm how they do it?
On Thu, 25 Apr 2002, Bruce Momjian wrote:
>
> Marc is suggesting we may want to match Oracle somehow.
>
> I just want to have our SET work on a sane manner.
As do I. But to Marc's suggestion, we discussed an oracle compatibility
factor in the past and it was dismissed. I seem to recall someone
Marc is suggesting we may want to match Oracle somehow.
I just want to have our SET work on a sane manner.
---
Vince Vielhaber wrote:
> On Thu, 25 Apr 2002, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > > > My gu
On Thu, 25 Apr 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > > My guess is that we should implement #1 and see what feedback we get in
> > > 7.3.
> >
> > IMHO, it hasn't been thought out well enough to be implemented yet ... the
> > options have been, but which to implement haven't ...
Marc G. Fournier wrote:
> > My guess is that we should implement #1 and see what feedback we get in
> > 7.3.
>
> IMHO, it hasn't been thought out well enough to be implemented yet ... the
> options have been, but which to implement haven't ... right now, #1 is
> proposing to implement something t
On Thu, 25 Apr 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > Okay, based on this, I'm pseudo-against ... I think, for reasons of
> > reducing headaches for ppl posting, there should be some sort of 'SET
> > oracle_quirks' operation that would allow for those with largish legacy
> > app
Marc G. Fournier wrote:
> Okay, based on this, I'm pseudo-against ... I think, for reasons of
> reducing headaches for ppl posting, there should be some sort of 'SET
> oracle_quirks' operation that would allow for those with largish legacy
> apps trying to migrate over to do so without having to c
On Thu, 25 Apr 2002, Mike Mascari wrote:
> Bruce Momjian wrote:
> >
> > Marc G. Fournier wrote:
> > >
> > > Just curious here, but has anyone taken the time to see how others are
> > > doing this? For instance, if we go with 1, are going against how everyone
> > > else handles it? IMHO, its not
Bruce Momjian wrote:
>
> Marc G. Fournier wrote:
> >
> > Just curious here, but has anyone taken the time to see how others are
> > doing this? For instance, if we go with 1, are going against how everyone
> > else handles it? IMHO, its not a popularity contest ...
>
> Yes, good point. I don'
Marc G. Fournier wrote:
>
> Just curious here, but has anyone taken the time to see how others are
> doing this? For instance, if we go with 1, are going against how everyone
> else handles it? IMHO, its not a popularity contest ...
Yes, good point. I don't know that they use SET, but if they
Sander Steffann wrote:
> > What about a SET variable that controls the behaviour of
> > SET variables :-)
>
> Or two commands for the same thing:
> - a SET command that behaves as it does now
> - a TSET command that is transaction-aware
>
> Ouch... :-)
> Sander
Naw, that's far too eas
> What about a SET variable that controls the behaviour of
> SET variables :-)
Or two commands for the same thing:
- a SET command that behaves as it does now
- a TSET command that is transaction-aware
Ouch... :-)
Sander
---(end of broadcast)---
Just curious here, but has anyone taken the time to see how others are
doing this? For instance, if we go with 1, are going against how everyone
else handles it? IMHO, its not a popularity contest ...
Personally, I do agree with #1, but I'm curious as to how those coming
from other DBMS are go
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> >
> > Must I understand this from your previous posting
> > (2 says roll back only after transaction aborts,)
> > or original posting ? What I understood was 2 only
> > says that SET fails between a failure and the
> > subsequenct ROLLBACK call.
>
>
Bruce Momjian wrote:
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > Hiroshi Inoue wrote:
> > > > Bruce Momjian wrote:
> > > > >
> > > > > > > >
> > > > > > > > I voted not only ? but also 2 and 3.
> > > > > > > > And haven't I asked twice or so if it's a vote ?
> > > > > > >
> > > >
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > > Bruce Momjian wrote:
> > > >
> > > > > > >
> > > > > > > I voted not only ? but also 2 and 3.
> > > > > > > And haven't I asked twice or so if it's a vote ?
> > > > > >
> > > > > > Yes, it is a vote, and now that we se
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > > > >
> > > > > > I voted not only ? but also 2 and 3.
> > > > > > And haven't I asked twice or so if it's a vote ?
> > > > >
> > > > > Yes, it is a vote, and now that we see how everyone feels, we can
> > > > > dec
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > > > >
> > > > > I voted not only ? but also 2 and 3.
> > > > > And haven't I asked twice or so if it's a vote ?
> > > >
> > > > Yes, it is a vote, and now that we see how everyone feels, we can
> > > > decide what to do.
> > > >
> > > > Hiroshi,
Bruce Momjian wrote:
>
> > > >
> > > > I voted not only ? but also 2 and 3.
> > > > And haven't I asked twice or so if it's a vote ?
> > >
> > > Yes, it is a vote, and now that we see how everyone feels, we can
> > > decide what to do.
> > >
> > > Hiroshi, you can't vote for 2, 3, and ?.
> >
> > W
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > > Bruce Momjian wrote:
> > > >
> > > > OK, the votes are in:
> > > >
> > > > #1
> > > > Lamar Owen
> > > > Jan Wieck
> > > > Tom Lane
> > > > Bruce Momjian
> > > > Joe Conw
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > OK, the votes are in:
> > >
> > > #1
> > > Lamar Owen
> > > Jan Wieck
> > > Tom Lane
> > > Bruce Momjian
> > > Joe Conway
> > > Curt Sampson
> > > Mich
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > OK, the votes are in:
> >
> > #1
> > Lamar Owen
> > Jan Wieck
> > Tom Lane
> > Bruce Momjian
> > Joe Conway
> > Curt Sampson
> > Michael Loftis
> > Vince Vielhaber
> >
Bruce Momjian wrote:
>
> OK, the votes are in:
>
> #1
> Lamar Owen
> Jan Wieck
> Tom Lane
> Bruce Momjian
> Joe Conway
> Curt Sampson
> Michael Loftis
> Vince Vielhaber
> Sander Steffann
>
> #2
> Brad
OK, the votes are in:
#1
Lamar Owen
Jan Wieck
Tom Lane
Bruce Momjian
Joe Conway
Curt Sampson
Michael Loftis
Vince Vielhaber
Sander Steffann
#2
Bradley McLean
76 matches
Mail list logo
