Evgeny Potemkin wrote:
> Hi Guilhem, Øystein,
>
> On 03/09/10 18:08, Guilhem Bichot wrote:
>> Hello,
>> (Evgeny, there is a question for you below, please search for "Evgeny"),
>>
>> Øystein Grøvlen a écrit, Le 02.03.2010 13:00:
>>> Hi Guilhem,
>>>
>>> Thanks for documenting what you found. I have some comments/questions
>>> inline.
>>>
>>> Guilhem Bichot wrote:
>>>> #At
>>>> file:///home/mysql_src/bzrrepos/mysql-6.0-codebase-bugfixing-50361/
>>>> based on revid:guilhem@stripped
>
> [skip]
>
>>>> === modified file 'sql/sql_lex.h'
>>>> --- a/sql/sql_lex.h 2010-02-05 16:57:46 +0000
>>>> +++ b/sql/sql_lex.h 2010-02-24 09:11:25 +0000
>>>> @@ -557,9 +557,15 @@ public:
>>>> SQL_LIST group_list; /* GROUP BY clause. */
>>>> List<Item> item_list; /* list of fields & expressions */
>>>> List<String> interval_list;
>>>> + /**
>>>> + Name resolution in Item_field::fix_fields() searches for a name in
>>>> + tables' columns' names; if this boolean is true, it is allowed to
>>>> + additionally look up in SELECT's item_list (necessary to find aliased
>>>> + fields).
>>>> + */
>>>
>>> Why is "is allowed to" more appropriate than "needs to"?
>>
>> It "needs to" look into item_list only if there are fields which it
>> cannot find in tables.
>> It is allowed to look into item_list.
>> In other places, I guess it would be wrong to look into item_list, when
>> only real column names are wanted?
>> Which is why "allowed to" would be correct here?
>> This member was introduced for
>>
>> http://bugs.mysql.com/bug.php?id=7672
>>
>> (Evgeny's fix), with this comment:
>>
>> "When fixing Item_func_plus in ORDER BY clause field c is searched in
>> all opened tables, but because c is an alias it wasn't found there."
>> It's tested in Item_field::fix_fields().
>> Evgeny, please, could you give a good comment for this member?
>>
>>> "tables' columns' names" was a bit difficult to parse.
>>
>> ok
>>
>>>> bool is_item_list_lookup;
> This thing is needed for resolving ORDER BY (and, AFAIR, GROUP BY) items.
> For example
> SELECT a, b AS f2 FROM t1 ORDER BY a, func(f2)
> 'a' will be successfully resolved against t1, but f2 won't. For such cases
> it's allowed for ORDER BY to do item list look up to find items.
> In case of 'a' table look up is enough, so ORDER BY doesn't "need to" do
> look at item list.
In the SQL standard, the SELECT statement is defined in terms of a table expression:
table expression> ::=
<from clause>
[ <where clause> ]
[ <group by clause> ]
[ <having clause> ]
[ <window clause> ]
and we have the SELECT, aka. query specification:
<query specification> ::=
SELECT [ <set quantifier> ] <select list> <table expression>
Thus, expressions in where clause, group by clause and having clause can only
refer to columns from the from clause, or columns that are outer references.
ORDER BY is defined in a cursor specification:
<query expression> [ <order by clause> ] [ <updatability clause> ]
(query expression is basically <query specification> [UNION <query spec>...])
ORDER BY can refer to columns from the select list, including aliased columns.
It can also refer to other columns of the underlying tables, with some limitations.
Resolving aliases from the select list in GROUP BY (and HAVING?) is a MySQL
extension.
Adding ORDER BY to any subquery is also a MySQL extension.
Roy
