From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: session server side variables |
Date: | 2016-12-28 14:04:13 |
Message-ID: | CAFj8pRBhPBDOcjfeaPwpv2GoEu9ebbTaaJD-m6P49EJQbpBakA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2016-12-28 15:00 GMT+01:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:
> On 28 December 2016 at 21:19, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2016-12-28 14:16:34 | Re: [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups |
Previous Message | Craig Ringer | 2016-12-28 14:01:39 | [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups |