Re: CREATE OR REPLACE FUNCTION vs ownership - Mailing list pgsql-hackers

From Tom Lane
Subject Re: CREATE OR REPLACE FUNCTION vs ownership
Date
Msg-id 18172.1254494961@sss.pgh.pa.us
Whole thread Raw
In response to Re: CREATE OR REPLACE FUNCTION vs ownership  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: CREATE OR REPLACE FUNCTION vs ownership
List pgsql-hackers
KaiGai Kohei <kaigai@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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Postgres server goes in recovery mode repeteadly
Next
From: Heikki Linnakangas
Date:
Subject: Re: Hot Standby on git