Re: Controlling changes in plpgsql variable resolution

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Controlling changes in plpgsql variable resolution
Дата
Msg-id 14405.1256159603@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Controlling changes in plpgsql variable resolution  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
Josh Berkus <josh@agliodbs.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Controlling changes in plpgsql variable resolution
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Controlling changes in plpgsql variable resolution