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