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.2861 05/06/23 14:47:58 jon@stripped +3 -0
news-4-1-13, news-5-0-8:
Documenting bugfixes -
Bug#7967
Bug#9361
news-5-0-8:
New behaviour/warning regarding column aliases
used as grouping column names. (Ref. Bug#11211)
Sync refman-4.1, refman-5.0 to refman tree.
refman/news.xml
1.23 05/06/23 14:47:55 jon@stripped +57 -0
Documenting bugfixes:
Bug#7967
Bug#9361
news-5-0-8:
New behaviour/warning regarding column aliases
used as grouping column names. (Ref. Bug#11211)
refman-5.0/news.xml
1.19 05/06/23 14:47:55 jon@stripped +57 -0
Sync to refman tree.
refman-4.1/news.xml
1.19 05/06/23 14:47:54 jon@stripped +57 -0
Sync to refman tree.
# 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.site
# Root: /home/jon/bk/mysqldoc
--- 1.18/refman-4.1/news.xml 2005-06-23 13:12:09 +10:00
+++ 1.19/refman-4.1/news.xml 2005-06-23 14:47:54 +10:00
@@ -246,6 +246,44 @@
for prepared statements. (Bug #8367, Bug #9334)
</para></listitem>
+ <listitem>
+ <para>Where a <literal>GROUP BY</literal> query uses a grouping
+ column from the query's <literal>SELECT</literal> clause, MySQL
+ now issues a warning. This is because the SQL standard states that
+ any grouping column must unambiguously reference a column of the
+ table resulting from the query's <literal>FROM</literal> clause,
+ and allowing columns from the <literal>SELECT</literal> clause to
+ be used as grouping columns is a MySQL extension to the standard.</para>
+ <para>By way of example, consider the following two tables:</para>
+<programlisting>
+CREATE TABLE users (
+ userid INT NOT NULL PRIMARY KEY,
+ username VARCHAR(25),
+ usergroupid INT NOT NULL
+);
+</programlisting>
+ <para>MySQL allows you to use the alias in this query:</para>
+<programlisting>
+SELECT usergroupid AS id, COUNT(userid) AS number_of_users
+FROM groups
+GROUP BY id;
+</programlisting>
+ <para>However, the SQL standard requires the the column name be
+ used, as shown here:</para>
+<programlisting>
+SELECT usergroupid AS id, COUNT(userid) AS number_of_users
+FROM groups
+GROUP BY userid;
+</programlisting>
+ <para>Queries such as the first of the two shown above will
+ continue to be supported in MySQL; however, beginning with MySQL
+ 5.0.8, using a column alias in this fashion will generate a
+ warning. Note that in the event of a collision between column
+ names and/or aliases used in joins, MySQL attempts to resolve the
+ conflict by giving preference to columns arising from tables named
+ in the query's <literal>FROM</literal> clause. (Bug #11211)</para>
+ </listitem>
+
</itemizedlist>
<para>
@@ -291,6 +329,13 @@
</listitem>
<listitem>
+ <para>The <literal>mysqlhotcopy</literal> script was not parsing
+ the output of <literal>SHOW SLAVE STATUS</literal> correctly when
+ called with the <literal>--record_log_pos</literal> option.
+ (Bug #7967)</para>
+ </listitem>
+
+ <listitem>
<para><literal>SELECT * FROM <replaceable>table</replaceable></literal>
returned incorrect results when called from a stored procedure,
where <replaceable>table</replaceable> had a primary key.
@@ -4356,6 +4401,18 @@
report success even though the database was not in fact changed.
(Bug #9148,
<ulink url="http://cve.mitre.org/cvename.cgi?name=CAN-2005-0799">CAN-2005-0799</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para>The <literal>mysqlhotcopy</literal> script was not parsing
+ the output of <literal>SHOW SLAVE STATUS</literal> correctly when
+ called with the <literal>--record_log_pos</literal> option.
+ (Bug #7967)</para>
+ </listitem>
+
+ <listitem>
+ <para>An <literal>UPDATE</literal> query containing a subselect
+ caused replication to fail. (Bug #9361)</para>
</listitem>
<listitem>
--- 1.18/refman-5.0/news.xml 2005-06-23 13:12:09 +10:00
+++ 1.19/refman-5.0/news.xml 2005-06-23 14:47:55 +10:00
@@ -246,6 +246,44 @@
for prepared statements. (Bug #8367, Bug #9334)
</para></listitem>
+ <listitem>
+ <para>Where a <literal>GROUP BY</literal> query uses a grouping
+ column from the query's <literal>SELECT</literal> clause, MySQL
+ now issues a warning. This is because the SQL standard states that
+ any grouping column must unambiguously reference a column of the
+ table resulting from the query's <literal>FROM</literal> clause,
+ and allowing columns from the <literal>SELECT</literal> clause to
+ be used as grouping columns is a MySQL extension to the standard.</para>
+ <para>By way of example, consider the following two tables:</para>
+<programlisting>
+CREATE TABLE users (
+ userid INT NOT NULL PRIMARY KEY,
+ username VARCHAR(25),
+ usergroupid INT NOT NULL
+);
+</programlisting>
+ <para>MySQL allows you to use the alias in this query:</para>
+<programlisting>
+SELECT usergroupid AS id, COUNT(userid) AS number_of_users
+FROM groups
+GROUP BY id;
+</programlisting>
+ <para>However, the SQL standard requires the the column name be
+ used, as shown here:</para>
+<programlisting>
+SELECT usergroupid AS id, COUNT(userid) AS number_of_users
+FROM groups
+GROUP BY userid;
+</programlisting>
+ <para>Queries such as the first of the two shown above will
+ continue to be supported in MySQL; however, beginning with MySQL
+ 5.0.8, using a column alias in this fashion will generate a
+ warning. Note that in the event of a collision between column
+ names and/or aliases used in joins, MySQL attempts to resolve the
+ conflict by giving preference to columns arising from tables named
+ in the query's <literal>FROM</literal> clause. (Bug #11211)</para>
+ </listitem>
+
</itemizedlist>
<para>
@@ -291,6 +329,13 @@
</listitem>
<listitem>
+ <para>The <literal>mysqlhotcopy</literal> script was not parsing
+ the output of <literal>SHOW SLAVE STATUS</literal> correctly when
+ called with the <literal>--record_log_pos</literal> option.
+ (Bug #7967)</para>
+ </listitem>
+
+ <listitem>
<para><literal>SELECT * FROM <replaceable>table</replaceable></literal>
returned incorrect results when called from a stored procedure,
where <replaceable>table</replaceable> had a primary key.
@@ -4356,6 +4401,18 @@
report success even though the database was not in fact changed.
(Bug #9148,
<ulink url="http://cve.mitre.org/cvename.cgi?name=CAN-2005-0799">CAN-2005-0799</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para>The <literal>mysqlhotcopy</literal> script was not parsing
+ the output of <literal>SHOW SLAVE STATUS</literal> correctly when
+ called with the <literal>--record_log_pos</literal> option.
+ (Bug #7967)</para>
+ </listitem>
+
+ <listitem>
+ <para>An <literal>UPDATE</literal> query containing a subselect
+ caused replication to fail. (Bug #9361)</para>
</listitem>
<listitem>
--- 1.22/refman/news.xml 2005-06-23 13:12:10 +10:00
+++ 1.23/refman/news.xml 2005-06-23 14:47:55 +10:00
@@ -246,6 +246,44 @@
for prepared statements. (Bug #8367, Bug #9334)
</para></listitem>
+ <listitem>
+ <para>Where a <literal>GROUP BY</literal> query uses a grouping
+ column from the query's <literal>SELECT</literal> clause, MySQL
+ now issues a warning. This is because the SQL standard states that
+ any grouping column must unambiguously reference a column of the
+ table resulting from the query's <literal>FROM</literal> clause,
+ and allowing columns from the <literal>SELECT</literal> clause to
+ be used as grouping columns is a MySQL extension to the standard.</para>
+ <para>By way of example, consider the following two tables:</para>
+<programlisting>
+CREATE TABLE users (
+ userid INT NOT NULL PRIMARY KEY,
+ username VARCHAR(25),
+ usergroupid INT NOT NULL
+);
+</programlisting>
+ <para>MySQL allows you to use the alias in this query:</para>
+<programlisting>
+SELECT usergroupid AS id, COUNT(userid) AS number_of_users
+FROM groups
+GROUP BY id;
+</programlisting>
+ <para>However, the SQL standard requires the the column name be
+ used, as shown here:</para>
+<programlisting>
+SELECT usergroupid AS id, COUNT(userid) AS number_of_users
+FROM groups
+GROUP BY userid;
+</programlisting>
+ <para>Queries such as the first of the two shown above will
+ continue to be supported in MySQL; however, beginning with MySQL
+ 5.0.8, using a column alias in this fashion will generate a
+ warning. Note that in the event of a collision between column
+ names and/or aliases used in joins, MySQL attempts to resolve the
+ conflict by giving preference to columns arising from tables named
+ in the query's <literal>FROM</literal> clause. (Bug #11211)</para>
+ </listitem>
+
</itemizedlist>
<para>
@@ -291,6 +329,13 @@
</listitem>
<listitem>
+ <para>The <literal>mysqlhotcopy</literal> script was not parsing
+ the output of <literal>SHOW SLAVE STATUS</literal> correctly when
+ called with the <literal>--record_log_pos</literal> option.
+ (Bug #7967)</para>
+ </listitem>
+
+ <listitem>
<para><literal>SELECT * FROM <replaceable>table</replaceable></literal>
returned incorrect results when called from a stored procedure,
where <replaceable>table</replaceable> had a primary key.
@@ -4356,6 +4401,18 @@
report success even though the database was not in fact changed.
(Bug #9148,
<ulink url="http://cve.mitre.org/cvename.cgi?name=CAN-2005-0799">CAN-2005-0799</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para>The <literal>mysqlhotcopy</literal> script was not parsing
+ the output of <literal>SHOW SLAVE STATUS</literal> correctly when
+ called with the <literal>--record_log_pos</literal> option.
+ (Bug #7967)</para>
+ </listitem>
+
+ <listitem>
+ <para>An <literal>UPDATE</literal> query containing a subselect
+ caused replication to fail. (Bug #9361)</para>
</listitem>
<listitem>
| Thread |
|---|
| • bk commit - mysqldoc@docsrva tree (jon:1.2861) | jon | 23 Jun |
