Re: Per-function GUC settings: trickier than it looked - Mailing list pgsql-hackers
From | Florian G. Pflug |
---|---|
Subject | Re: Per-function GUC settings: trickier than it looked |
Date | |
Msg-id | 46DC9586.3040102@phlo.org Whole thread Raw |
In response to | Re: Per-function GUC settings: trickier than it looked (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Per-function GUC settings: trickier than it looked
|
List | pgsql-hackers |
Tom Lane wrote: > "Florian G. Pflug" <fgp@phlo.org> writes: >> And the rule becomes (I tend to forget things, so I like simple >> rules that I can remember ;-) ) "For each SET-clause, there is >> a pseudo-subtransaction affecting only *this* GUC". > > The other question is whether we want to change the behavior of SET > LOCAL even in the absence of function SET-clauses. The current rule > is that a LOCAL setting goes away at subtransaction commit, leading > to this behavior: > > regression=# show regex_flavor; > regex_flavor > -------------- > advanced > (1 row) > > regression=# begin; > BEGIN > regression=# savepoint x; > SAVEPOINT > regression=# set local regex_flavor to basic; > SET > regression=# release x; > RELEASE > regression=# show regex_flavor; > regex_flavor > -------------- > advanced > (1 row) > > which makes some sense if you think of "release" as "subtransaction > end", but not a lot if you think of it as forgetting a savepoint. > Likewise, SET LOCAL within a plpgsql exception block goes away at > successful block exit, which is not the first thing you'd expect. > Neither of these behaviors are documented anywhere AFAIR; certainly > the SET reference page doesn't explain 'em. > > I think we should probably take this opportunity to fix that, and > make SET LOCAL mean "persists until end of current top-level > transaction, unless rolled back earlier or within a function SET > clause". > > So: > > * Plain SET takes effect immediately and persists unless rolled back > or overridden by another explicit SET. In particular the value will > escape out of a function that has a SET-clause for the same variable. > > * SET LOCAL takes effect immediately and persists until rolled back, > overridden by another SET, or we exit a function that has a SET-clause > for the same variable. > > * Rollback of a transaction or subtransaction cancels any SET or SET > LOCAL within it. Otherwise, the latest un-rolled-back SET or SET LOCAL > determines the active value within a transaction, and the latest > un-rolled-back SET determines the value that will prevail after the > transaction commits. > > * A function SET clause saves the entry-time value, and restores it at > function exit, except when overridden by an un-rolled-back SET (but not > SET LOCAL) within the function. > > Clear to everyone? Any objections? That makes "SET LOCAL" completely equivalent to "SET", except when used inside a function that has a corresponding SET-clause, right? So I think *if* this is done, "SET LOCAL" should be renamed to "SET FUNCTION". This would also prevent confusion, because everyone who currently uses SET LOCAL will have to change his code anyway, since the semantics change for every use-case apart from functions with SET-clauses, which don't exist in 8.2. Or am I overlooking something? And renaming SET LOCAL also emphasized that point that we are taking away functionality here - even if that functionality might not seem very useful. BTW, I *did* check the documentation before responding to Simon's original mail, and I *did* read it as "SET LOCAL goes away a subtransaction end". I figured that since there is no word on subtransactions in that part of the documentation, transaction will apply equally to both toplevel and subtransaction. It might very well be that I'm the only one who read it that way, though ;-) And I must admin that I wasn't completely sure, so I *did* try it out before I posted... I'd strong prefer "SET LOCAL" to kept it's current semantics, only that "SET LOCAL" changes will now be rolled back if the function has a matching SET-clause. For multiple reasons: .) It's useful to be able to temporarily change GUCs from a client, and being ableto reset them afterwards. Using a subtransaction for this is maybe a bit wastefull, but at least it works. .) Inpl/pgsql, that fact that "SET LOCAL" goes away after the current BEGIN/END block seems entirely logical. .) It doesn'ttake away existing functionality greetings, Florian Pflug
pgsql-hackers by date: