RE: Feature Request: ALTER FUNCTION (or something like that)

Actually,

This reminds me of something I have been meaning to ask.  All the new
performance features are cool, but what I really need are all the ALTER
TABLE ... functions implemented.  In 7.0.x you could only add columns and
foreign keys.  You couldn't drop anything or add stuff like CHECK
constraints.  Has this situation changed for 7.1?

Regards,

Chris

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Joel Burton
Sent: Wednesday, 28 March 2001 8:39 AM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Feature Request: ALTER FUNCTION (or something like
that)



(I know that everyone is focusing on 7.1. This is a question about how
hard it would be to plan a feature for 7.2 or later)

One of the small annoyances in PG is that I use many functions to handle
small details, and these functions are called by views. If I want to
improve a function, I have to drop and recreate those views (and all views
that depend on them, etc.)

If I understand everything, this is because the function OID is used to
call the function, not its name.

How difficult would it be to either

. allow creation of a function using a specific OID? (CREATE FUNCTION
USING OID xxxxx ...)

or

. add a command like ALTER FUNCTION foo(text) TO foo(text) returns text as
....

Then, (presumably?) the calling functions and views could just find the
function by its old oid.

This would seem to require that the new function would take the same
parameters (and return the same?) as the old function. This could be
handled either as a runtime check by the ALTER command, or it could be
left as caveat functioner.

Perhaps this is tricky, or perhaps there's already a great solution. (If
so, please tell!) If I'm making an idiot of myself, do let me know.

Otherwise, is this feasible? I could try my rusty hand at C, but I'd need
someone to give me a 2-paragraph game plan on where to start playing with
the code.

Thanks!


(of course, this raises the same question for VIEWs... dropping and
creating them is a pain b/c of the same reasons...)


--
Joel Burton   <jburton@scw.org>
Director of Information Systems, Support Center of Washington


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