Re: Controlling changes in plpgsql variable resolution

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Controlling changes in plpgsql variable resolution
Date: 2009-10-21 21:13:23
Message-ID: 14405.1256159603@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> That's what the #option alternative is for. Yes, it's a bit ugly, but
>> it's perfectly functional, and secure too.

> I still don't see why it's needed. If the function owner simply sets
> the option in the function definitions (as a userset), it doesn't matter
> what the calling user sets, does it?

If we do it that way, it is safe only if *every* *single* plpgsql
function has an attached SET option for this. Otherwise a function's
own setting will propagate to its callees. This is error-prone and will
be pretty bad for performance too --- the per-function SET mechanism
isn't especially cheap and was never meant to be used by every last
function.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-10-21 21:13:33 Re: Controlling changes in plpgsql variable resolution
Previous Message Tom Lane 2009-10-21 21:02:51 Re: Controlling changes in plpgsql variable resolution