Whilst fooling with the default ACLs patch I noticed that there's a
pre-existing bug in CREATE OR REPLACE FUNCTION. It will let you
replace a function if pg_proc_ownercheck passes, which these days
does *not* mean that you are exactly the role mentioned in
pg_proc.proowner; it only means you are some member of that role.
It then proceeds with the function replacement, while keeping the
old proowner value. It then proceeds to wipe out the old dependency
info and record *you* as the owner in pg_shdepend. So pg_shdepend
will be inconsistent with proowner if you're a member of the owning
role but not running with SET ROLE to the owning role.
(I was led to this after noticing that the patch similarly bollixes
the grant dependencies ...)
My inclination is to think that the right behavior for REPLACE FUNCTION
is to keep the old proowner and proacl values, because that's what it
always has done and nobody's complained. But I suppose a case could
be made that you're completely replacing the function and so you should
replace its ownership/permissions too. The CREATE FUNCTION reference
page fails to specify either way, which is a documentation bug as well.
Whichever way you think it should work, there's a bug here that goes
back several versions, and I rather suspect we may have the same issue
for other REPLACE-type commands ...
regards, tom lane
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2009-10-01 22:49:45|
|Subject: Re: FSM search modes |
|Previous:||From: Kevin Grittner||Date: 2009-10-01 22:17:20|
|Subject: Re: FSM search modes|