Re: Should we get rid of custom_variable_classes altogether?

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Should we get rid of custom_variable_classes altogether?
Дата
Msg-id 4E89C58D.5010803@dunslane.net
обсуждение исходный текст
Ответ на Re: Should we get rid of custom_variable_classes altogether?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Should we get rid of custom_variable_classes altogether?
Список pgsql-hackers

On 10/03/2011 10:17 AM, Tom Lane wrote:
> Magnus Hagander<magnus@hagander.net>  writes:
>> Don't forget that there are usecases for variables under
>> custom_variable_classes that aren't actually associated with
>> extensions (as general session-shared-variables). Though I guess if it
>> was somehow restricted to extensions, those who needed that could just
>> rewrap all their code as extensions - though that would make it less
>> convenient.
> Right.  Getting rid of custom_variable_classes should actually make
> those use-cases easier, since it will eliminate a required setup step.
>
> I tried to think of a security argument for keeping the setting, but
> couldn't really.  Yeah, not having it will let people clutter their
> individual backend's GUC array with lots of useless stuff, but so what?
> There's plenty of other ways to run your session out of memory if you're
> so inclined.
>
>             


So are we going to sanction using this as a poor man's session variable 
mechanism?

If so maybe we should at least warn that anything set will be accessible 
by all roles, so security definer functions for example should be wary 
of trusting such values.

cheers

andrew




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Should we get rid of custom_variable_classes altogether?
Следующее
От: Pavel Stehule
Дата:
Сообщение: SPI_processed is not set for COPY statement