Re: BUG #16603: Permission issue - Mailing list pgsql-bugs

From Stephen Frost
Subject Re: BUG #16603: Permission issue
Date
Msg-id 20200901161648.GW29590@tamriel.snowman.net
Whole thread Raw
In response to BUG #16603: Permission issue  (PG Bug reporting form <noreply@postgresql.org>)
List pgsql-bugs
Greetings,

* PG Bug reporting form (noreply@postgresql.org) wrote:
> The following MySQL query: GRANT ALL PRIVILEGES ON database_name.* TO
> 'username'@'localhost'; allows one to assign one database to a given user.
> That includes ALL permissions even database creation.

> Currently this behavior is impossible in PostgreSQL: One can create a
> database and GRANT ALL PRIVILEGES however this won't grant the CREATEDB
> permission on that database. The bug/issue here is that CREATEDB cannot be
> assigned to a specific database/user combination.

No, it's not currently possible to GRANT access to objects that don't
exist in PG.  This isn't a bug, as for if it's a possible future
feature, maybe (there's a current patch that I'm working on to GRANT
things like 'read only' or 'write only' access to all tables/views/etc),
but I don't expect to ever support the ability for GRANT to explicitly
name an object that doesn't exist yet (seems like it'd be rather
concerning too, because what if someone *else* created that database?
Suddenly this user has access to it?  No, thanks).

> Currently this bug prevents development of some applications. As such in one
> of my application I was forced to drop support for PostgreSQL and return to
> MySQL.

This hasn't ever worked in PG, so it seems a little curious that it's
the cause for PG support to be dropped.  Still, it's definitely not a
bug and certainly wouldn't be added to existing releases.  If you're
interested in following the development of PG, I'd suggest you take a
look at the -hackers mailing list.

Thanks,

Stephen

Attachment

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #16603: Permission issue
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #16594: DROP INDEX CONCURRENTLY fails on partitioned table with a non helpful error message.