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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Date: 2005-03-12 16:35:40
Message-ID: (view raw or whole thread)
Lists: pgsql-patches
Neil Conway <neilc(at)samurai(dot)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

In response to


pgsql-patches by date

Next:From: Marko KreenDate: 2005-03-12 20:59:39
Subject: Re: pgcrypto: openssl digest fix
Previous:From: Neil ConwayDate: 2005-03-12 15:37:55
Subject: Re: Display Pg buffer cache (WIP)

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