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
PLso 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@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
