MySQL Bugs: #6885: Crash with table and column named SOME

Bug #6885	Crash with table and column named SOME
Submitted:	29 Nov 2004 22:22	Modified:	10 Mar 2005 15:12
Reporter:	Peter Gulutzan	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	4.1.8-debug	OS:	Linux (SuSE 8.2)
Assigned to:	Antony Curtis	CPU Architecture:	Any

Description:
I have a table named SOME and a column named SOME. 
I use the names in a context which might cause confusion since SOME(subquery) is legal. 
The server crashes. 
 
By the way, I notice that SOME is a reserved word according to the SQL:2003 standard, 
but not a reserved word in MySQL. 
 

How to repeat:
mysql> create table some (some int); 
Query OK, 0 rows affected (0.39 sec) 
 
mysql> select * from some where some.s1 > some (select some from some); 
ERROR 2013 (HY000): Lost connection to MySQL server during query

Can verify with
5.0.2-alpha-debug-log
[23:42] root@test>create table some (some int);
Query OK, 0 rows affected (0.31 sec)

5.0.2-alpha-debug-log
[23:42] root@test>select * from some where some.s1 > some (select some from some);
ERROR 2013 (HY000): Lost connection to MySQL server during query

Verified with  4.1.8-debug-log

(gdb) bt
#0  0x08136f38 in Item_subselect::fix_fields (this=0x8cc3dd8, thd_param=0x8cbc538, tables=0x8cc39e0, ref=0x8cc494c)
    at item_subselect.cc:178
#1  0x0818b83a in setup_conds (thd=0x8cbc538, tables=0x8cc39e0, conds=0x8cc494c) at sql_base.cc:2599
#2  0x0819016f in JOIN::prepare (this=0x8cc3f80, rref_pointer_array=0x8cbc76c, tables_init=0x8cc39e0, wild_num=1,
    conds_init=0x8cc3dd8, og_num=0, order_init=0x0, group_init=0x0, having_init=0x0, proc_param_init=0x0,
    select_lex_arg=0x8cbc668, unit_arg=0x8cbc580) at sql_select.cc:229
#3  0x081937b3 in mysql_select (thd=0x8cbc538, rref_pointer_array=0x8cbc76c, tables=0x8cc39e0, wild_num=1,
    fields=@0x8cbc6d0, conds=0x8cc3dd8, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=8669696,
    result=0x8cc3f70, unit=0x8cbc580, select_lex=0x8cbc668) at sql_select.cc:1564
#4  0x0818feec in handle_select (thd=0x8cbc538, lex=0x8cbc574, result=0x8cc3f70) at sql_select.cc:193
#5  0x0816d96f in mysql_execute_command (thd=0x8cbc538) at sql_parse.cc:2009
#6  0x081724d1 in mysql_parse (thd=0x8cbc538,
    inBuf=0x8cc38d8 "select * from some where some.s1 > some (select some from some)", length=63) at sql_parse.cc:4074
#7  0x0816c642 in dispatch_command (command=COM_QUERY, thd=0x8cbc538,
    packet=0x8cbe751 "select * from some where some.s1 > some (select some from some)", packet_length=64)
    at sql_parse.cc:1494
#8  0x0816bf62 in do_command (thd=0x8cbc538) at sql_parse.cc:1280
#9  0x0816b53b in handle_one_connection (arg=0x8cbc538) at sql_parse.cc:1024
#10 0xb7e4714b in pthread_start_thread () from /lib/libpthread.so.0
#11 0xb7e471df in pthread_start_thread_event () from /lib/libpthread.so.0
#12 0xb7d7a50a in clone () from /lib/libc.so.6

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/22848

Thank you for taking the time to report a problem.  Unfortunately
you are not using a current version of the product your reported a
problem with -- the problem might already be fixed. Please download
a new version from http://www.mysql.com/downloads/

If you are able to reproduce the bug with one of the latest versions,
please change the version on this bug report to the version you
tested and change the status back to "Open".  Again, thank you for
your continued support of MySQL.