On Mon, 2007-09-03 at 04:09 -0500, Decibel! wrote: > On Sun, Sep 02, 2007 at 12:08:00PM -0400, Tom Lane wrote: > > I notice BTW that we have never updated the SET reference page since > > subtransactions were introduced --- it still says only that SET LOCAL > > is "local to the current transaction", without a word about > > subtransactions. So we have a documentation problem anyway. I recall > > that we had some discussion during the 8.0 dev cycle about whether > > having SET LOCAL's effects end at the end of the current subtransaction > > was really a good idea, given that subtransactions aren't the conceptual > > model the SQL spec defines, but nothing was ever done about changing > > the implementation. > > ISTM that's the real problem; SET LOCAL wasn't fully updated/considered > when subtransactions were added. > > One way to handle this would be to have 3 different behaviors for SET: > session-level, transaction-level, and sub-transaction level. If we had > that, we could probably make an across-the-board call that all functions > operate as if in their own sub-transaction, at least when it comes to > SET.
What would be the use case for that? I can't see a single reason to do a SET LOCAL SUBTRANSACTION or whatever you'd call it. What you suggest sounds nicely symmetrical, but I don't think we need it in practice. ISTM that SET LOCAL is mostly superceded by per-function parameters. Most parameters need to be tied to code, not transactions. Of course, my wish to use synchronous_commit *was* tied to a transaction, but not a subtransaction. per-function parameters are sorely needed anyhow, since with session pools we can't easily use the username for SET parameters. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
