Re: [HACKERS] proposal: session server side variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] proposal: session server side variables
Date
Msg-id CAFj8pRBhPBDOcjfeaPwpv2GoEu9ebbTaaJD-m6P49EJQbpBakA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] proposal: session server side variables  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [HACKERS] proposal: session server side variables
Re: [HACKERS] proposal: session server side variables
List 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 by date:

Previous
From: Craig Ringer
Date:
Subject: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups
Next
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vslookups