"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
* 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 b
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_US
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 w
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.
* 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
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
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 a
* 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 im
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
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
* 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
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 w
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 thin
* 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 s
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).
Acco
* 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
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 (a
* 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
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 r
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
> 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.
This is true, and was discussed quite a bit about
21 matches
Mail list logo
