On Mon, May 28, 2012 at 10:39 AM, Aren Cambre <a...@arencambre.com> wrote:
> Looks like pgAdmin's user handling is broken or nonsensical. Just as a > test, I created a new login role named *test*. Here's its SQL: > *CREATE ROLE test LOGIN* > * ENCRYPTED PASSWORD 'md505a671c66aefea124cc08b76ea6d30bb'* > * NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;* > > Then I went to the *Tables* section of one of a db's schemas, started the > *Grant Wizard*, then went to the *Privileges *tab, and this *test*account > doesn't appear in the > *Role* dropdown. All I see is *public*. If I type in *test*, I can't > press *Add/Change *no matter what I select in *Privileges*. > > This doesn't make sense. If I create a login role, it should show up here > and allow me to assign it to arbitrary tables. > That's intentional (and configurable): see http://www.pgadmin.org/support/faq.php#UserPrivileges > > And I can confirm that pgAdmin is not acting correctly through direct SQL. > If I run this: > *grant select on txdot_roadways_3081_transform to gis;* > > (*gis *is the account I was trying to use earlier.) Then I can select > from that table using that account via another program.' > > That's what I'd expect to happen - the GRANT applies to any user interface, not just pgAdmin. (I'll leave the default privs stuff for Guillaume to comment on, as he wrote that and I'm not overly familiar with it and am pressed for time right now). -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
