Re: Per-function GUC settings: trickier than it looked - Mailing list pgsql-hackers

From Brendan Jurd
Subject Re: Per-function GUC settings: trickier than it looked
Date
Msg-id 37ed240d0709041311i6d84e8fdg9847fa4b4b5391d1@mail.gmail.com
Whole thread Raw
In response to Re: Per-function GUC settings: trickier than it looked  (Michael Paesold <mpaesold@gmx.at>)
Responses Re: Per-function GUC settings: trickier than it looked
List pgsql-hackers
On 9/5/07, Michael Paesold <mpaesold@gmx.at> wrote:
> Tom Lane wrote:
> > Basically my perspective on SET LOCAL is that its current behavior is a
> > bug, and even though it's been that way for a couple major releases now,
> > it's still something we oughta fix while we are busy whacking that part
> > of the code around.  Florian's example with SET TRANSACTION READ ONLY
> > proves that it's a bug --- RELEASE is not defined to change any
> > transaction modes.
>
> Yeah, I think your original proposal was really sound. I would not
> expect the current SET LOCAL behaviour in the context of savepoints.
> If we really need the current behaviour, we should find a new name for
> this lasts-until-savepoint-release-or-transaction-end thingy.

So, if I read you correctly, in summary we'd like to:
* make SET LOCAL local to the transaction (i.e., make it behave as documented),* abandon the idea of a
subtransaction-localSET, because the new
 
function-local SET takes care of the interesting use-cases for that,* somehow deal with the incompatibility with the
8.2"security
 
definer" workaround.

Tom's proposal to handle the latter was that when a function-local SET
reverts, it overrides any inner SET LOCALs.

Am I on the right page?

Cheers,
BJ


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_dump and insert multi-rows option
Next
From: "korry.douglas"
Date:
Subject: Re: Has anyone tried out the PL/pgSQL debugger?