Robert Haas wrote: > On Thu, Oct 1, 2009 at 8:52 PM, Euler Taveira de Oliveira > <eu...@timbira.com> wrote: >> David E. Wheeler escreveu: >>> On Oct 1, 2009, at 3:42 PM, Tom Lane wrote: >>> >>>> 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? >>> The latter, I think. If I replace a function, I should be the new owner. >>> To me it makes no sense for someone else to own it. >>> >> Hmm... Using the same logic, if I add a new column should I be the table >> owner? If you're changing the function that is because you have permission. >> >> IMHO the owner should be preserved. In my mind, REPLACE is for changing the >> content and not the properties (name, owner, etc).
If so, it seems to me CREATE OR REPLACE is equivalent to ALTER FUNCTION with currently unsupported option. In this case, it is not necessary to check CREATE privilege on the namespace because it does not affect to its name/schema. > I disagree. I think David has this one right. I expect the results > of CREATE OR REPLACE to be the same as the result of CREATE would have > been had the object not existed. If so, it seems to me CREATE OR REPLACE is equivalent to a pair of actions: 1) DROP FUNCTION (if exist) and 2) CREATE FUNCTION. I think the current implementation intend the later perspective. (It also checks ownership of the older definition, only if exists.) However, I'm not sure which is the better way, currently. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
