From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tom(dot)Zschockelt(at)flender(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #2032: grant role bug |
Date: | 2005-11-10 14:26:01 |
Message-ID: | 8599.1131632761@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tom(dot)Zschockelt(at)flender(dot)com writes:
> here is an 'real' output of psql in our test scenario.
I tried to duplicate this example, but it still works fine for me.
> testdb1=> \du
> List of users
> User name | User ID | Attributes | Groups
> -----------+---------+----------------------------+-----------------
> allgemein | 22584 | | {g_usermgr_use}
> enduser | 24364 | | {g_usermgr_use}
> postgres | 10 | superuser, create database |
> usermgr | 22583 | |
> (4 rows)
This makes me suspicious, because you are evidently using an 8.0 (or
older) psql; 8.1's \du output does not look like that. While using an
old psql with a new backend shouldn't affect the behavior of GRANT,
I wonder whether this is a symptom of pilot error at another level.
Is it possible that you are talking to an 8.0 postmaster as one user
and an 8.1 postmaster as the other user? Then the two "testdb1"
databases wouldn't be the same database at all. You can use
"select version()" and "show data_directory" to positively confirm
the identity of the postmaster you are connected to.
> testdb1=> \dp+
> Access privileges for database "testdb1"
> Schema | Name | Type | Access privileges
> --------+------+------+-------------------
> (0 rows)
I believe this only shows stuff that is in your search path, which the
usermgr schema wouldn't be by default for enduser. Try
\dp usermgr.*
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2005-11-10 15:13:56 | Re: BUG #2034: Wrong time zone IST |
Previous Message | Neeraj Malhotra | 2005-11-10 12:10:27 | BUG #2034: Wrong time zone IST |