Sorry to ressurect this thread. However, I've been playing with the new
role system and I'd prefer to keep CURRENT_USER as the login user, and
not making it a synonymn for CURRENT_ROLE. In my application, I love the
ability to shed privleges by SET ROLE dataentry;. However, I need
CURRENT_USER
* Clark C. Evans ([EMAIL PROTECTED]) wrote:
Sorry to ressurect this thread. However, I've been playing with the new
role system and I'd prefer to keep CURRENT_USER as the login user, and
not making it a synonymn for CURRENT_ROLE. In my application, I love the
ability to shed privleges by SET
Clark C. Evans [EMAIL PROTECTED] writes:
Sorry to ressurect this thread. However, I've been playing with the new
role system and I'd prefer to keep CURRENT_USER as the login user, and
not making it a synonymn for CURRENT_ROLE. In my application, I love the
ability to shed privleges by SET
Is there a TODO here?
---
Peter Eisentraut wrote:
Am Samstag, 25. M?rz 2006 16:10 schrieb Tom Lane:
No, the current implementation is a compromise between exact standards
compatibility and backwards compatibility with
Stephen Frost wrote:
I also feel that we really can't do what
the SQL spec requires without seperating users from roles as I don't
beleve you're supposed to be able to grant users to roles or set role
to a user.
Actually, for my proposal to work, we *must* keep users and roles the
same.
Am Samstag, 25. März 2006 01:02 schrieb Stephen Frost:
If there are use cases where what we're doing is causing problems for
users who are looking for what the SQL spec has exactly, please let us
know.. Given that other databases don't religiously follow the SQL spec
wrt roles either makes me
Peter Eisentraut [EMAIL PROTECTED] writes:
My concern here is to arrive at a standards conforming role system. Clearly
we've established that the current one doesn't do it. Moreover, I'm now
convinced that some aspects of the current implementation arose from an
attempt to implement the
* Tom Lane ([EMAIL PROTECTED]) wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
My concern here is to arrive at a standards conforming role system.
Clearly
we've established that the current one doesn't do it. Moreover, I'm now
convinced that some aspects of the current
Am Samstag, 25. März 2006 16:10 schrieb Tom Lane:
No, the current implementation is a compromise between exact standards
compatibility and backwards compatibility with our historical groups
behavior. I'm not really prepared to toss the latter overboard.
My two major sticking points here are
Am Samstag, 25. März 2006 17:27 schrieb Stephen Frost:
I think what Peter would want is for us to track CURRENT_USER (the role
who logged in) and to always add the CURRENT_USER to the list of roles
available after a 'SET ROLE'. That would at least get us a little
closer to the spec though I'm
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Am Samstag, 25. März 2006 17:27 schrieb Stephen Frost:
I think what Peter would want is for us to track CURRENT_USER (the role
who logged in) and to always add the CURRENT_USER to the list of roles
available after a 'SET ROLE'. That would at
Stephen Frost wrote:
Is there a particular issue/problem you're running into? It might
make more sense to focus on what you actually need than what the spec
says you need...
The particular issue I'm running into is that I'm trying to get the
information schema up to speed but the current
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Is there a particular issue/problem you're running into? It might
make more sense to focus on what you actually need than what the spec
says you need...
The particular issue I'm running into is that I'm trying to get the
Stephen Frost wrote:
Well.. Applicable roles are roles which you can SET ROLE to, but
which you don't automatically get the permissions of (inherit). As I
recall, the spec wants all roles to be like this until an explicit
SET ROLE is done. When a SET ROLE is done, then that role (and
all
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Well.. Applicable roles are roles which you can SET ROLE to, but
which you don't automatically get the permissions of (inherit). As I
recall, the spec wants all roles to be like this until an explicit
SET ROLE is done.
Stephen Frost wrote:
You were talking about 'enabled' vs. 'applicable' roles. Above
they're talking about 'enabled authorization identifiers' (the list
of roles you currently have the permissions of) and 'applicable
privileges' (the specific privileges you have as that set of roles).
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
You were talking about 'enabled' vs. 'applicable' roles. Above
they're talking about 'enabled authorization identifiers' (the list
of roles you currently have the permissions of) and 'applicable
privileges' (the specific
Stephen Frost [EMAIL PROTECTED] writes:
Eh, it does and it doesn't. The SQL standard says that no roles are
automatically inheirited and that you have to 'set role' to them. Thus,
all non-user roles which are granted to users in Postgres would need to
be defined 'noinherit' to have things
Stephen Frost wrote:
Eh, it does and it doesn't. The SQL standard says that no roles are
automatically inheirited and that you have to 'set role' to them.
Thus, all non-user roles which are granted to users in Postgres would
need to be defined 'noinherit' to have things work as the spec
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Eh, it does and it doesn't. The SQL standard says that no roles are
automatically inheirited and that you have to 'set role' to them.
Thus, all non-user roles which are granted to users in Postgres would
need to be
Trying to work in the new role features into the information schema, I
noticed that there might be a few incompatibilities between the
implementation and what the SQL standard would like to see.
The way I understand this is that, according to the SQL standard, there
should be a current user
21 matches
Mail list logo
