| От | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера