Re: [HACKERS] proposal: session server side variables

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] proposal: session server side variables
Дата
Msg-id CAFj8pRBhPBDOcjfeaPwpv2GoEu9ebbTaaJD-m6P49EJQbpBakA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] proposal: session server side variables  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: [HACKERS] proposal: session server side variables
Re: [HACKERS] proposal: session server side variables
Список pgsql-hackers
Дерево обсуждения


2016-12-28 15:00 GMT+01:00 Craig Ringer <craig@2ndquadrant.com>:
On 28 December 2016 at 21:19, Fabien COELHO <coelho@cri.ensmp.fr> wrote:

> Also, I'm not yet convinced that simple privatizable transcient/session
> variables would not be enough to fit the use case, so that for the same
> price there would be session variables for all, not only special ones with
> permissions.

Since, unlike Oracle, we don't have compiled packages or plan-caching
above the session level, there's not the same hard requirement for the
variable definition to be persistent.

So... maybe? The main question then becomes how you integrate access control.

For security the variable should be persistent.

If you would to do statical analyse (what you usually would), then variable should be persistent.

Currently the big issue of plpgsql_check is work with temporary tables. Local objects or dynamic sql is stop for static check.

Regards

Pavel
 

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vslookups