Sorry, I oversight this report.
The reason of this confusing error message is originated by incorrect
aclkind being delivered to aclcheck_error() at AlterObjectOwner_internal().
/* New owner must have CREATE privilege on namespace */
if (OidIsValid(namespaceId))
{
AclResult aclresult;
aclresult = pg_namespace_aclcheck(namespaceId, new_ownerId,
ACL_CREATE);
if (aclresult != ACLCHECK_OK)
aclcheck_error(aclresult, aclkind,
get_namespace_name(namespaceId));
}
The supplied aclkind represents the property of the object being re-owned,
not a namespace that owns the target object. So, right approach is to
give ACL_KIND_NAMESPACE being hardwired in this case, as
AlterObjectNamespace_internal() doing.
The attached patch fixes this trouble.
postgres=# create role clerks;
CREATE ROLE
postgres=# create role bob in role clerks;
CREATE ROLE
postgres=# create schema foo;
CREATE SCHEMA
postgres=# grant usage on schema foo to bob, clerks;
GRANT
postgres=# create aggregate
postgres-# foo.sum(basetype=text,sfunc=textcat,stype=text,initcond='');
CREATE AGGREGATE
postgres=# alter aggregate foo.sum(text) owner to bob;
ALTER AGGREGATE
postgres=# set role bob;
SET
postgres=> alter aggregate foo.sum(text) owner to clerks;
ERROR: permission denied for schema foo
Thanks,
2012/12/20 Robert Haas <robertmhaas@gmail.com>:
> This looks busted:
>
> rhaas=# create role clerks;
> CREATE ROLE
> rhaas=# create role bob in role clerks;
> CREATE ROLE
> rhaas=# create schema foo;
> CREATE SCHEMA
> rhaas=# grant usage on schema foo to bob, clerks;
> GRANT
> rhaas=# create aggregate
> foo.sum(basetype=text,sfunc=textcat,stype=text,initcond='');
> CREATE AGGREGATE
> rhaas=# alter aggregate foo.sum(text) owner to bob;
> ALTER AGGREGATE
> rhaas=# set role bob;
> SET
> rhaas=> alter aggregate foo.sum(text) owner to clerks;
> ERROR: permission denied for function foo
>
> Eh? There's no function called foo. There's a schema called foo,
> which seems to be the real problem: clerks needs to have CREATE on foo
> in order for bob to complete the rename. But somehow the error
> message is confused about what type of object it's dealing with.
>
> [ Credit: The above example is adapted from an EDB-internal regression
> test, the failure of which was what alerted me to this problem. ]
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
