Most of the groundwork for sprint task 729 (implement FUNCTIONs).

Expanded the mysql.proc table, reworked the find/create/drop functions
completely, added new functions for FUNCTIONs (lotta functions here :),
got rid of some unnecessary use of Item_strings while at it. Extended
the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs
coexist with UDFs.
Can now CREATE and DROP FUNCTIONs. Invoking yet to come...

1 files changed, 12 insertions, 2 deletions

diff --git a/Docs/sp-implemented.txt b/Docs/sp-implemented.txt
index 97d4df2b62c..b3b12b7edb8 100644
--- a/Docs/sp-implemented.txt
+++ b/Docs/sp-implemented.txt
@@ -11,6 +11,8 @@ Summary of Not Yet Implemented:
   - SQL-99 COMMIT (related to BEGIN/END)
   - DECLARE CURSOR ...
   - FOR-loops (as it requires cursors)
+  - CASCADE/RESTRICT for ALTER and DROP
+  - ALTER/DROP METHOD (as it implies User Defined Types)
 
 
 Summary of what's implemented:
@@ -66,15 +68,23 @@ List of what's implemented:
       databases.)
 
 
-Open questions:
+Closed questions:
 
   - What is the expected result when creating a procedure with a name that
     already exists? An error or overwrite?
+  Answer: Error
+
   - Do PROCEDUREs and FUNCTIONs share namespace or not? I think not, but the
     we need to flag the type in the mysql.proc table and the name alone is
     not a unique key any more, or, we have separate tables.
     (Unfortunately, mysql.func is already taken. Use "sfunc" and maybe even
      rename "proc" into "sproc" while we still can, for consistency?)
+  Answer: Same tables, with an additional key-field for the type.
+
+
+Open questions:
+
   - SQL-99 variables and parameters are typed. For the present we don't do
     any type checking, since this is the way MySQL works. I still don't know
-    if we should keep it this way, or implement type checking.
+    if we should keep it this way, or implement type checking. Possibly we
+    should have optional, uset-settable, type checking.