Re: Support for %TYPE in CREATE FUNCTION

Ian Lance Taylor wrote:
> [...]
> I propose this: if a table definition changes, alter the function to
> use the new type (choice 2). If there is already a function with the
> new type, issue a NOTICE and drop the old function (choice 23b). If
> something is using the old function, issue a NOTICE while dropping the
> old function (choice 2b).

Altering a function definition in any language other than
PL/pgSQL really scares me. What do you expect a "C" function
declared to take a VARCHAR argument to do if you just change
the pg_proc entry telling it now takes a NAME? I'd expect it
to generate a signal 11 most of it's calls, and nothing
really useful the other times.

And you have no chance of limiting your implementation to
functions defined in PL/pgSQL. It's a loadable PL so you
don't even know the languages or handlers Oid at compile
time.

> If you agree with me on the meta-point, then this is just a quibble
> about my original patch (which made choice 1 above). If you disagree
> with me, I'd like to understand why.

The possible SIGSEGV above. Please don't take it personally,
I'm talking tech here, but it seems you forgot that PL/pgSQL
is just *one* of many possible languages.

And please forget about a chance to finally track all
dependencies. You'll never be able to know if some PL/Tcl or
PL/Python function/trigger uses that function. So not getting
your NOTICE doesn't tell if really nothing broke. As soon as
you tell me you can I'd implement PL/Forth or PL/Pascal -
maybe PL/COBOL or PL/RPL (using an embedded HP48 emulator)
just to tell "you can't" again :-)

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com