Re: proposal: session server side variables

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, 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-29 08:11:22
Message-ID: alpine.DEB.2.20.1612290831530.4911@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello Jim,

>> Yes if the private variable should be accessed. If the variable is
>> private, then it is private and nothing is needed. Idem for public.
> Why force the extra busywork? Just allow for them to be public.

There is no extra busywork, having possibly private session variables cost
nearly nothing, and I'm arguing that they could be enough for Pavel
special use case.

> For that matter, if we're going to start introducing private objects, that
> certainly needs to be thought through.

Yep. It is a discussion.

>> One can get the permissions on special session variable wrong as well...
>> I do not see how it differs.
> It's a lot harder to mess up an explicit grant than it is to mess up object
> ownership.

ISTM that it rather depends on the default permissions on the object... If
a variable object is publicly accessible by default, then you have to take
care about revoke & grant and you can mess up with it. Moreover, it also
suggest that session variables could be private by default.

>> *(at)db> SELECT secfunc2(); -- returns: "postgres - fabien" from both
>> sides...
> Perhaps I've got the restrictions on SECDEF wrong, but I know there's
> problems with it. Certainly one issue is you can't change roles back to the
> calling user.

It is the same with suid executable on Unix, I do not see as an issue.

> Maybe they would be workable in this case, but it's just a bunch of extra
> busywork for the user that serves no real purpose.

Pavel special case is the purpose.

> Then IMHO what needs to happen is to have a discussion on actual syntax
> instead of calling into question the value of the feature.

I think that the discussion should be *both* about syntax and semantics.

> Following this thread has been very painful because the communications
> have not been very clear.

Yep. The fact that I initially missed the "half persistence" property of
Pavel's design has not helped.

I suggest to move the discussion on the following wiki page that I have
just bootstrapped:


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2016-12-29 08:36:28 Re: proposal: session server side variables
Previous Message Alvaro Herrera 2016-12-29 07:28:07 Re: Indirect indexes