1 files changed, 112 insertions, 0 deletions
diff --git a/Docs/sp-implemented.txt b/Docs/sp-implemented.txt
new file mode 100644
index 00000000000..6f2cf49b3b0
--- /dev/null
+++ b/Docs/sp-implemented.txt
@@ -0,0 +1,112 @@
+Stored Procedures implemented 2004-01-29:
+
+
+Summary of what's implemented:
+
+  - SQL PROCEDUREs/FUNCTIONs (CREATE/DROP)
+  - CALL
+  - DECLARE of local variables
+  - BEGIN/END, SET, CASE, IF, LOOP, WHILE, REPEAT, ITERATE, LEAVE
+  - SELECT INTO local variables
+  - "Non-query" FUNCTIONs only
+  - Prepared SP caching
+  - CONDITIONs and HANDLERs
+  - Simple read-only CURSORs.
+  - SHOW CREATE PROCEDURE/FUNCTION and SHOW PROCEDURE/FUNCTION STATUS
+
+
+Summary of Not Yet Implemented:
+
+  - SQL statements using tables (like SELECT, INSERT, UPDATE etc) in FUNCTIONs
+  - External languages
+  - Access control
+  - SQL-99 COMMIT (related to BEGIN/END)
+  - FOR-loops
+  - CASCADE/RESTRICT for ALTER and DROP
+  - ALTER/DROP METHOD (as it implies User Defined Types)
+  - SIGNAL and RESIGNAL, and UNDO handlers
+
+
+List of what's implemented:
+
+  - CREATE PROCEDURE|FUNCTION name ( args ) characteristics body
+    where characteristics is:
+      LANGUAGE SQL |
+      [NOT] DETERMINISTIC |
+      SQL SECURITY [DEFINER|INVOKER] |
+      COMMENT string
+    However the DETERMINISTIC setting is not currently used.
+
+  - ALTER PROCEDURE|FUNCTION name characteristics
+    CASCADE/RESTRICT is not implemented.
+    characteristics is:
+      COMMENT string |
+      SQL SECURITY [DEFINER|INVOKER] |
+      NAME newname
+
+  - DROP PROCEDURE|FUNCTION [IF EXISTS] name
+    CASCADE/RESTRICT is not implemented.
+
+  - CALL name (args)
+    OUT and INOUT parameters are also works for user variables ("global"
+    variables) - i.e., if a procedure is defined as:
+      CREATE PROCEDURE foo(OUT p INT) ...;
+    a call like:
+      CALL foo(@x);
+    will set @x to the output value.
+
+  - Function/Procedure body:
+    - BEGIN/END
+      Is parsed, but not the real thing with (optional) transaction
+      control, it only serves as block syntax for multiple statements (and
+      local variable binding).
+      Note: Multiple statements requires a client that can send bodies
+            containing ";". This is handled in the CLI clients mysql and
+	    mysqltest with the "delimiter" command. Changing the end-of-query
+	    delimiter ";" to for instance "|" allows ";" to be used in the
+	    routine body.
+    - SET of local variables
+      Implemented as part of the pre-existing SET syntax. This allows an
+      extended syntax of "SET a=x, b=y, ..." where different variable types
+      (SP local and global) can be mixed. This also allows combinations
+      of local variables and some options that only make sense for
+      global/system variables; in that case the options are accepted but
+      ignored.
+    - The flow control constructs: CASE, IF, LOOP, WHILE, ITERATE and LEAVE
+      are fully implemented.
+    - SELECT ... INTO local variables (as well as global session variables)
+      is implemented. (Note: This is not SQL-99 feature, but common in other
+      databases.)
+    - A FUNCTION can have flow control contructs, but must not contain
+      an SQL query/statement, like SELECT, INSERT, UPDATE, etc. The reason
+      is that it's hard to allow this is that a FUNCTION is executed as part
+      of another query (unlike a PROCEDURE, which is called as a statement).
+      The table locking scheme used makes it difficult to allow "subqueries"
+      during FUNCTION invokation.
+    - SPs are cached, but with a separate cache for each thread (THD).
+      There are still quite a few non-reentrant constructs in the lexical
+      context which makes sharing prepared SPs impossible. And, even when
+      this is resolved, it's not necessarily the case that it will be faster
+      than a cache per thread. A global cache requires locks, which might
+      become a bottleneck. (It would save memory though.)
+    - CONDITIONs and HANDLERs are implemented, but not the SIGNAL and
+      RESIGNAL statements. (It's unclear if these can be implemented.)
+      The semantics of CONDITIONs is expanded to allow catching MySQL error
+      codes as well. UNDO handlers are not implemented (since we don't have
+      SQL-99 style transaction control yet).
+    - Simple read-only CURSORs are implemented, but not yet any of the
+      optional arguments to DECLARE (SCROLL, SENSITIVE, etc) or FETCH
+      (NEXT, PRIOR, etc). Cursors are ASENSITIVE, READ-ONLY, non-SCROLLing.
+      (The additional syntax will be added for completeness, but for the
+       most part unsupported with the current underlying cursor mechanism.)
+      N.B. The current implementation is temporary and only works within a
+        stored procedure, and may not perform well for very large result sets.
+        A "real" cursor implementation is under development; this will replace
+        the current one when it's finished.
+
+  - SHOW procedures and functions
+    SHOW CREATE PROCEDURE|FUNCTION <name>
+      returns the definition of a routine.
+    SHOW PROCEDURE|FUNCTION STATUS [LIKE <pattern>]
+      returns characteristics of routines, like the name, type, creator,
+      creation and modification dates, etc.