From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Per-function GUC settings: trickier than it looked |
Date: | 2007-09-02 02:22:04 |
Message-ID: | 23461.1188699724@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 "subtransaction" exit. (I'll post the code to
pgsql-patches in a moment.)
But on reflection I realize that there are some interesting properties
to this approach:
* if you do "SET LOCAL foo" when you are in a function that has a
"SET foo" property, the setting disappears at function exit. But if
you do "SET foo" it persists. This might be OK, but it seems a bit odd.
* in fact, if you do "SET LOCAL foo" when you are in a function that has
any "SET" property at all, the setting disappears at function exit,
whether foo was one of the variables SET by the function definition or
not.
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-09-02 02:51:48 | Re: synchronous_commit: Developer's View |
Previous Message | David Fetter | 2007-09-02 01:48:50 | Re: synchronous_commit: Developer's View |