Skip site navigation (1) Skip section navigation (2)


From: Neil Conway <neilc(at)samurai(dot)com>
To: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Date: 2005-03-12 13:43:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
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.


- 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.


Attachment: alter_function_strictness-3.patch
Description: text/x-patch (20.5 KB)


pgsql-patches by date

Next:From: Andrew DunstanDate: 2005-03-12 14:03:16
Subject: Re: pgsql: Handle carriage returns and line feeds in COPY
Previous:From: Neil ConwayDate: 2005-03-12 06:59:24
Subject: Re: pgcrypto: openssl digest fix

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group