Per-function GUC settings: trickier than it looked

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

Responses

Browse pgsql-hackers by date

  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