This patch allows ALTER FUNCTION set change a function's strictness. In
and of itself this isn't very useful, but it is defined in SQL2003, so
it's probably worth implementing.

Notes:

- the optimizer considers strictness; for example, the optimizer will
pre-evaluate calls to a strict function that is passed NULL (i.e.
replacing the function call with a NULL). This means if you create a
function, create a plan that calls the function, change the function's
strictness, and then invoke the stored plan, the function's old
strictness will still apply. Considering we have rather more serious
problems involving out-of-date plans following DDL, I don't think this
is a big deal, but I thought I'd mention it.

- SQL *requires* a "CASCADE" keyword following the ALTER command. I made
it optional, but even optional it's a little ugly.

- I considered making it possible to change other attributes of a
function (e.g. volatility and security definer), and the patch is
implemented such that this should be easy to do. Does anyone think this
is worth doing? (The same kinds of not-flushing-dependent-objects on
ALTER issues apply as with strictness and saved plans.)

- SQL also specifies that the LANGUAGE clause of the function definition
should be modifiable, but that strikes me as quite bizarre. The other
things SQL defines for ALTER FUNCTION don't have equivalents in PG
(<parameter style clause>, <SQL-data access indication>, <dynamic result
sets characteristic>, and NAME <external routine name>).

Incidentally, is there a reason that DROP FUNCTION doesn't use the
FuncWithArgs node? Given that the latter exists, ISTM we may as well use
it where applicable.

-Neil


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Neil Conway <neilc@samurai.com> writes:
> This patch allows ALTER FUNCTION set change a function's strictness. In
> and of itself this isn't very useful, but it is defined in SQL2003, so
> it's probably worth implementing.

You realize of course that that can already be done with CREATE OR
REPLACE FUNCTION. I think it's probably still somewhat useful to have
an ALTER, since the REPLACE way requires re-entering the whole function
body, which you very possibly don't want to change.

> - I considered making it possible to change other attributes of a
> function (e.g. volatility and security definer), and the patch is
> implemented such that this should be easy to do. Does anyone think this
> is worth doing?

Yes, on the same grounds as above.

> - SQL also specifies that the LANGUAGE clause of the function definition
> should be modifiable, but that strikes me as quite bizarre.

Indeed. It doesn't seem sensible to change LANGUAGE without supplying a
new function body, and so I would argue that this should be left to
CREATE OR REPLACE FUNCTION. But I can see wishing that I could change
the auxiliary properties of a function without retyping the body.

> Incidentally, is there a reason that DROP FUNCTION doesn't use the
> FuncWithArgs node?

Probably just historical, but why bother changing it? I don't think
that would let you accomplish anything useful, like consolidating
RemoveFuncStmt with something else. Nor would it make the code
measurably clearer IMHO.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Tom Lane wrote:
> You realize of course that that can already be done with CREATE OR
> REPLACE FUNCTION.

Good point; that makes me less wary of breaking dependencies on existing
functions via ALTER, since in any case that can already be done.

>>Incidentally, is there a reason that DROP FUNCTION doesn't use the
>>FuncWithArgs node?
>
> Probably just historical, but why bother changing it?

It's just a small cleanup, but it seems inconsistent to me to have an
abstraction "function name with args" that is only used in some of the
situations where it's applicable. I know, I'm ornery about these things

Attached is a revised patch that also allows security definer and
function volatility to be changed. Barring any objections, I'll apply
this tomorrow (I'm going to take a closer look at the patch before
applying it -- there might be a few details I want to polish up...)

-Neil


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Neil Conway wrote:
> Attached is a revised patch that also allows security definer and
> function volatility to be changed.

Applied.

-Neil

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org