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 statements.
> > > SET: for stuff that can be transactional.
> >
> > People keep suggesting this, and I keep asking for a concrete example
> > where non-rollback is needed, and I keep not getting one. I can't see
> > the value of investing work in creating an alternative behavior when
> > we have no solid example to justify it.
> >
> > The "Oracle compatibility" argument would have some weight if we were
> > making any concerted effort to be Oracle-compatible across the board;
> > but I have not detected any enthusiasm for that. Given that it's not
> > even the same syntax ("SET ..." vs "ALTER SESSION ...") I'm not sure
> > why an Oracle user would expect it to behave exactly the same.
>
> Agreed. OK, let me summarize.
>
> We had a vote that was overwhemingly #1. Marc made a good point that we
> should see how other databases behave, and we now know that Oracle and
> Ingres do #3 (honor all SETs in an aborted transaction). Does anyone
> want to change their vote from #1 to #3.
>
> 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 the original post :(
I withdraw my GUC variable desire, unless/until someone does go with an
'ALTER SESSION' command ...
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
