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.

 *@db> SELECT secfunc2(); -- returns: "postgres - fabien" from both

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:



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to