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. Comments? 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers