Below is the list of changes that have just been committed into a local
mysqldoc repository of jon. When jon does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.3431 05/08/31 21:40:42 jon@stripped +5 -0
refman/refman-5.0/refman-5.1: Added info
& example to stored routines chapter on
how order of precedence in variable names
vs. column names affects SELECT INTO. Also
added note to restrictions appendix
(5.0/5.1 only). (Thanks, Trudy!)
refman/stored-procedures.xml
1.19 05/08/31 21:40:40 jon@stripped +37 -2
Order of precedence, variable names vs. column names.
refman-5.1/stored-procedures.xml
1.10 05/08/31 21:40:40 jon@stripped +37 -0
Order of precedence, variable names vs. column names.
refman-5.1/restrictions.xml
1.7 05/08/31 21:40:40 jon@stripped +10 -0
Order of precedence, variable names vs. column names.
refman-5.0/stored-procedures.xml
1.11 05/08/31 21:40:40 jon@stripped +37 -0
Order of precedence, variable names vs. column names.
refman-5.0/restrictions.xml
1.8 05/08/31 21:40:40 jon@stripped +10 -0
Order of precedence, variable names vs. column names.
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: jon
# Host: gigan.
# Root: /home/jon/bk/mysqldoc
--- 1.6/refman-5.1/restrictions.xml 2005-08-18 22:00:16 +10:00
+++ 1.7/refman-5.1/restrictions.xml 2005-08-31 21:40:40 +10:00
@@ -51,6 +51,16 @@
All of the restrictions for stored functions also apply to
triggers.
</para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: If an SQL statement, such
+ as a <literal>SELECT ... INTO</literal> statement, contains a
+ reference to a column and a declared local variable with the same
+ name, MySQL interprets the reference as the name of a variable.
+ This is non-standard behaviour; the order of precedence is usually
+ column names, then SQL variables and parameters. See
+ <xref linkend="select-into-statement"/>.
+ </para>
<para>
Stored routines cannot contain arbitrary SQL statements. The
--- 1.9/refman-5.1/stored-procedures.xml 2005-08-31 01:52:00 +10:00
+++ 1.10/refman-5.1/stored-procedures.xml 2005-08-31 21:40:40 +10:00
@@ -895,6 +895,43 @@
See <xref linkend="variables"/>.
</para>
+ <para>
+ <emphasis role="bold">Important</emphasis>: SQL variable names
+ should not be the same as column names. If an SQL statement,
+ such as a <literal>SELECT ... INTO</literal> statement,
+ contains a reference to a column and a declared local variable
+ with the same name, MySQL currently interprets the reference
+ as the name of a variable. For example, in the following
+ statement, <literal>xname</literal> is interpreted as a
+ reference to the <literal>xname</literal>
+ <emphasis>variable</emphasis> rather than the
+ <literal>xname</literal> <emphasis>column</emphasis>:
+ </para>
+
+<programlisting>
+CREATE PROCEDURE sp1 (x VARCHAR(5))
+ BEGIN
+ DECLARE xname VARCHAR(5) DEFAULT 'bob';
+ DECLARE newname VARCHAR(5);
+ DECLARE xid INT;
+
+ SELECT xname,id INTO newname,xid
+ FROM table1 WHERE xname = xname;
+ SELECT newname;
+ END;
+</programlisting>
+
+ <para>
+ When this procedure is called, the
+ <literal>newname</literal> variable will return the value
+ <literal>'bob'</literal> regardless of the value of the
+ <literal>table1.xname</literal> column.
+ </para>
+
+ <para>
+ See also <xref linkend="routine-restrictions"/>.
+ </para>
+
</section>
</section>
--- 1.18/refman/stored-procedures.xml 2005-08-31 01:51:32 +10:00
+++ 1.19/refman/stored-procedures.xml 2005-08-31 21:40:40 +10:00
@@ -539,8 +539,10 @@
<indexterm type="function">
<primary>ALTER FUNCTION</primary>
</indexterm>
-
-<!-- Yes, the entire characteristics clause is optional... -->
+
+ <remark role="note">
+ Yes, the entire characteristics clause is optional...
+ </remark>
<programlisting>
ALTER {PROCEDURE | FUNCTION} <replaceable>sp_name</replaceable> [<replaceable>characteristic</replaceable> ...]
@@ -888,6 +890,39 @@
Note that user variable names are not case sensitive
beginning with MySQL 5.0.
See <xref linkend="variables"/>.
+ </para>
+
+ <para>
+ <emphasis role="bold">Important</emphasis>: SQL variable names
+ should not be the same as column names. If an SQL statement,
+ such as a <literal>SELECT ... INTO</literal> statement,
+ contains a reference to a column and a declared local variable
+ with the same name, MySQL currently interprets the reference
+ as the name of a variable. For example, in the following
+ statement, <literal>xname</literal> is interpreted as a
+ reference to the <literal>xname</literal>
+ <emphasis>variable</emphasis> rather than the
+ <literal>xname</literal> <emphasis>column</emphasis>:
+ </para>
+
+<programlisting>
+CREATE PROCEDURE sp1 (x VARCHAR(5))
+ BEGIN
+ DECLARE xname VARCHAR(5) DEFAULT 'bob';
+ DECLARE newname VARCHAR(5);
+ DECLARE xid INT;
+
+ SELECT xname,id INTO newname,xid
+ FROM table1 WHERE xname = xname;
+ SELECT newname;
+ END;
+</programlisting>
+
+ <para>
+ When this procedure is called, the
+ <literal>newname</literal> variable will return the value
+ <literal>'bob'</literal> regardless of the value of the
+ <literal>table1.xname</literal> column.
</para>
</section>
--- 1.7/refman-5.0/restrictions.xml 2005-08-29 01:09:20 +10:00
+++ 1.8/refman-5.0/restrictions.xml 2005-08-31 21:40:40 +10:00
@@ -51,6 +51,16 @@
All of the restrictions for stored functions also apply to
triggers.
</para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: If an SQL statement, such
+ as a <literal>SELECT ... INTO</literal> statement, contains a
+ reference to a column and a declared local variable with the same
+ name, MySQL interprets the reference as the name of a variable.
+ This is non-standard behaviour; the order of precedence is usually
+ column names, then SQL variables and parameters. See
+ <xref linkend="select-into-statement"/>.
+ </para>
<para>
Stored routines cannot contain arbitrary SQL statements. The
--- 1.10/refman-5.0/stored-procedures.xml 2005-08-31 01:51:56 +10:00
+++ 1.11/refman-5.0/stored-procedures.xml 2005-08-31 21:40:40 +10:00
@@ -892,6 +892,43 @@
See <xref linkend="variables"/>.
</para>
+ <para>
+ <emphasis role="bold">Important</emphasis>: SQL variable names
+ should not be the same as column names. If an SQL statement,
+ such as a <literal>SELECT ... INTO</literal> statement,
+ contains a reference to a column and a declared local variable
+ with the same name, MySQL currently interprets the reference
+ as the name of a variable. For example, in the following
+ statement, <literal>xname</literal> is interpreted as a
+ reference to the <literal>xname</literal>
+ <emphasis>variable</emphasis> rather than the
+ <literal>xname</literal> <emphasis>column</emphasis>:
+ </para>
+
+<programlisting>
+CREATE PROCEDURE sp1 (x VARCHAR(5))
+ BEGIN
+ DECLARE xname VARCHAR(5) DEFAULT 'bob';
+ DECLARE newname VARCHAR(5);
+ DECLARE xid INT;
+
+ SELECT xname,id INTO newname,xid
+ FROM table1 WHERE xname = xname;
+ SELECT newname;
+ END;
+</programlisting>
+
+ <para>
+ When this procedure is called, the
+ <literal>newname</literal> variable will return the value
+ <literal>'bob'</literal> regardless of the value of the
+ <literal>table1.xname</literal> column.
+ </para>
+
+ <para>
+ See also <xref linkend="routine-restrictions"/>.
+ </para>
+
</section>
</section>
| Thread |
|---|
| • bk commit - mysqldoc@docsrva tree (jon:1.3431) | jon | 31 Aug |
