-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 proposed
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 in
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 TRANSACTION an
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 without
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 part
of
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 interesting
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, but that's
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
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,
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
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 variable
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
to
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 overhead is
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 SET
LOCAL
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:
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 because in the
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
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 into a
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 value that
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?
What will
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
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
22 matches
Mail list logo
