* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Does it really? I don't think so. If you have owner privileges on the
> > schema you can grant create rights to the role, then either ALTER OWNER
> > if the patch is kept or just change to the role, create table
Stephen Frost <[EMAIL PROTECTED]> writes:
> Does it really? I don't think so. If you have owner privileges on the
> schema you can grant create rights to the role, then either ALTER OWNER
> if the patch is kept or just change to the role, create table x as
> select * from y;, etc, and then revoke
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > I don't like this approach to solving the problem. I would rather see
> > the check modified to allow the ownership change provided:
>
> > the user issueing the command has access to destination role
> > AND
> >
Stephen Frost <[EMAIL PROTECTED]> writes:
> I don't like this approach to solving the problem. I would rather see
> the check modified to allow the ownership change provided:
> the user issueing the command has access to destination role
> AND
> (
> the destination role can create the table
> O
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Considering I am superuser, it should darn well allow this.
Agreed.
> The problem of course is the test that u1 would have the rights to
> create t1 in s1, which he doesn't. I think we have to skip that
> test if superuser. As long as we need an explicit
postgres=# create user u1;
CREATE ROLE
postgres=# create schema s1;
CREATE SCHEMA
postgres=# create table s1.t1(f1 int);
CREATE TABLE
postgres=# alter table s1.t1 owner to u1;
ERROR: permission denied for schema s1
postgres=#
Considering I am superuser, it should darn well allow this.
The proble
