At 10:34 AM 4/26/02 -0400, Tom Lane wrote:
>Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> 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
Sorry, I wasn't clear enough. I'm not asking for non-rollback behaviour.
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 all. Anything that can't be rolled back shouldn't
> > Practical example: Does doing an enable seqscan affect OTHER db
> > and transactions as well?
>There are no SET commands that affect other backends. (There are
>GUC variables with system-wide effects, but we don't allow them to be
>changed by SET; rollback or not won't affect that.)
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2002-04-26 15:44:29|
|Subject: Re: pg_constraint |
|Previous:||From: Tom Lane||Date: 2002-04-26 15:20:52|
|Subject: Re: Vote totals for SET in aborted transaction |