KaiGai Kohei <kai...@ak.jp.nec.com> writes: > Robert Haas wrote: >> 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. But in fact CREATE OR REPLACE is *not* meant to be the same as DROP followed by CREATE. What it is meant to do is allow you to replace the implementation of the function while existing callers see it as still being the same function. Thus we prevent you from changing the name, arguments, or result type of the function. If we were to replace the permissions that would result in a more insidious but still real reason why former callers would suddenly stop working. In effect, permissions are part of the function's API. Another big reason not to change it is that it's worked like this ever since we had function permissions at all. It seems highly likely that we could introduce silent security breakages into applications that have been depending on the old behavior. I think the original reasoning for the behavior may have been that ownership/permissions are the only properties of the function that cannot be specified in the CREATE OR REPLACE FUNCTION syntax. It makes sense to leave them alone, because that is more likely to be right than reverting to default. 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