Davi Arnaut wrote:
> Sergei Golubchik wrote:
>> Hi!
>>
>> On Dec 10, Davi Arnaut wrote:
>>> Sergei Golubchik wrote:
>>>> On Dec 10, Davi Arnaut wrote:
>>>>> ChangeSet@stripped, 2007-12-10 11:34:12-02:00, davi@stripped +7 -0
>>>>> Bug#28317 Left Outer Join with {oj outer-join}
>>>>>
>>>>> Parser rejects ODBC's escape sequences for outer joins other than
>>>>> left outer join, yet the escape sequence BNF specifies that this
>>>>> syntax can be used for left, right, and full outer join syntax.
>>>> Why not to do it in the parser ? Lexer's task, conceptually, is to
>>>> split the input stream of characters into a stream of lexems. And
>>>> parser is supposed to apply grammar rules to the that.
>>> Practically speaking, because it introduces complexity and conflicts
>>> to the parser for something that in the first place shouldn't be
>>> handled by the server parser.
>> What complexity and conflicts ? '{' isn't used anywhere in SQL, there
>> could be no ambiguity.
>
> Look at the patch. See the rule for the left outer join.
>
>>> Conceptually speaking, a Lexer task is to do lexical analysis which is
>>> a "tokenization" process, but it doesn't me it must convert all
>>> characters into tokens. If the "lexeme" doesn't have any meaning,
>>> there is no point in passing it to the parser. This is quite common,
>>> you don't see parsers taking whitespace and comments into account.
>> Whitespace and comments - yes. But here there're three tokens: '{' 'oj'
>> ... '}' separated by other meaningful tokens. You cannot match and
>> remove them in a lexer, only a parser can do that. You can pretend that
>> lexer does it, but in fact it does it by embedding a simple parser,
>> that's all.
>>
>> To prove the point - your patch doesn't work, it doesn't handle nested
>> escapes, as far as I can see:
>>
>> SELECT ... FROM {oj t1 LEFT JOIN {oj t2 LEFT JOIN t3}}
>> SELECT ... FROM {oj t1 LEFT JOIN (SELECT * FROM {oj t2 LEFT JOIN t3})}
>
> And that was intentional, why should we support nested escapes?
Thinking more about it, although this one was intentional, the patch
breaks the parsing of other ODBC escape sequences. Patch retreated.
--
Davi Arnaut, Software Engineer
MySQL Inc, www.mysql.com
Are you MySQL certified? www.mysql.com/certification
