Re: timeout implementation issues

Heh pardon me but...

I was under the impression that for a transaction either all commands
succeed or all commands fail, atleast according to everything I've ever
read. So followign that all SETs done within the scope of a
BEGIN/COMMIT pair should only take effect if the whole set finishes, if
not the system shoudl roll back to the way it was before the BEGIN.

I might be missing something though, I just got onto the list and there
might be other parts of the thread I missed....

Karel Zak wrote:

>On Mon, Apr 08, 2002 at 01:03:41PM -0400, Tom Lane wrote:
>
>>The search_path case is the main reason why I'm intent on changing
>>the behavior of SET; without that, I'd just leave well enough alone.
>>
>
> Is there more variables like "search_path"? If not, I unsure if one
> item is good consideration for change others things.
>
>>Possibly some will suggest that search_path shouldn't be a SET variable
>>because it needs to be able to be rolled back on error. But what else
>>should it be? It's definitely per-session status, not persistent
>>
>
> It's good point. Why not make it more transparent? You want
> encapsulate it to standard and current SET statement, but if it's
> something different why not use for it different statement?
>
> SET SESSION search_path TO 'something';
>
> (...or something other)
>
> Karel
>