-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Sep 05, 2007 at 02:13:57PM +1000, Brendan Jurd wrote:
> On 9/5/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > > Am I on the right page?
> >
> > Got it in one, I believe.
>
> In that case, +1 for your
On 9/5/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > Am I on the right page?
>
> Got it in one, I believe.
In that case, +1 for your proposed changes.
At first, like Florian, I found the idea of a SET LOCAL ever
persisting beyond a function astonishing,
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> 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-local SET, because the new
> function-local SET takes care of the inter
On 9/5/07, Michael Paesold <[EMAIL PROTECTED]> 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 par
Tom Lane wrote:
Michael Paesold <[EMAIL PROTECTED]> writes:
I don't think it's a very good idea to make SET TRANSACTION an alias for
SET LOCAL, because SET TRANSACTION has already got its own meaning in the
SQL spec - it sets transaction modes.
Yeah --- I'm not sure we could even do it withou
Michael Paesold <[EMAIL PROTECTED]> writes:
> Florian G. Pflug wrote:
>> Hm... could we still have "SET TRANSACTION" as a synonym for "SET LOCAL"?
>> That would blend nicely with "SET TRANSACTION ISOLATION LEVEL" and
>> "SET TRANSACTION READ ONLY".
> I don't think it's a very good idea to make SET
Florian G. Pflug wrote:
Tom Lane wrote:
So, to reiterate, my idea is
.) Make "SET TRANSACTION" a synonym for "SET LOCAL" at the SQL-Level.
.) In pl/pgsql, "SET TRANSACTION" sets a new value that is kept after
the
function exits, even if the function has a matching SET-clause.
.) "SET LOCAL
Tom Lane wrote:
So, to reiterate, my idea is
.) Make "SET TRANSACTION" a synonym for "SET LOCAL" at the SQL-Level.
.) In pl/pgsql, "SET TRANSACTION" sets a new value that is kept after the
function exits, even if the function has a matching SET-clause.
.) "SET LOCAL" in pl/pgsql set a new val
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> It still seems a bit strange that "SET LOCAL" is undone at function-exit,
> if the function has a matching SET-clause. But we need that for backwards-
> compatibility of the secure-search_path workaround, right?
Yeah, I'm afraid we backed ourselves
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
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?
Maybe it wasn't clear :-(. They aren't e
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 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?
Maybe it wasn't clear :-(. They aren't equivalent beca
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> 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
"Florian G. Pflug" <[EMAIL PROTECTED]> 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 SE
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
At least for me, the least surprising behaviour would be to
revert it too. Than the rule becomes "a function is always
executed in a pseudo-subtransaction that affects only GUCs"
Only if it has at least one SET clause. The overhea
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> At least for me, the least surprising behaviour would be to
> revert it too. Than the rule becomes "a function is always
> executed in a pseudo-subtransaction that affects only GUCs"
Only if it has at least one SET clause. The overhead is too high
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
So it seems that only SET LOCAL within a function with per-function
GUC settings is at issue. I think that there is a pretty strong
use-case for saying that if you have a per-function setting of a
particular variabl
Simon Riggs <[EMAIL PROTECTED]> writes:
> ISTM that SET LOCAL is mostly superceded by per-function parameters.
Mostly, but not entirely. The case where you still need SET LOCAL is
where the value you want to use locally has to be computed, or where you
need to change it more than once within the
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"
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 doc
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We could perhaps get away with defining that as being the behavior,
>> but it doubtless will surprise someone sometime. What *should* these
>> interactions be like, and has anyone got an idea how to implement their
>> suggestion?
Tom Lane wrote:
So I coded up a patch for this, based on the idea of creating a
quasi-subtransaction that affects only GUC while entering/exiting a
function that has GUC settings attached. The specified settings are
applied as if by SET LOCAL before starting function execution, and then
they dro
So I coded up a patch for this, based on the idea of creating a
quasi-subtransaction that affects only GUC while entering/exiting a
function that has GUC settings attached. The specified settings are
applied as if by SET LOCAL before starting function execution, and then
they drop out during "subt
22 matches
Mail list logo
