rickywu-posh / php-sql-parser

Automatically exported from code.google.com/p/php-sql-parser
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Error: cannot calculate position of <tablename> #41

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Include a subquery in the column area of a 'Select' statement.
2. Be sure your subquery table name includes an escaped dollar symbol (e.g., 
v\$mytable)
3. You will get an error indicating the position of v\$mytable can't be found.

What is the expected output? What do you see instead?
I'm getting the error message in the subject indicating the position of the 
table cannot be found

What version of the product are you using? On what operating system?
The latest to date.

Please provide any additional information below.
I'm also curious why the comparisons in the where clause don't classify column 
comparisons (e.g., a.id=b.id) as JOINS instead of value/expression comparisons.

Original issue reported on code.google.com by kersn...@gmail.com on 10 Apr 2012 at 11:53

GoogleCodeExporter commented 8 years ago
Can you check the REV 240? I'm not sure, that I have understand you right. 
There is a test case for issue 41, is it correct?

Original comment by pho...@gmx.de on 26 Apr 2012 at 11:51

GoogleCodeExporter commented 8 years ago
additional information:

It is simpler to set value/expression types instead of JOINS. To find out, 
which columns of the WHERE clause are part of the join, I have to look for 
aliases too. This can be complicated, if you have subqueries instead of real 
tables. So the parser returns a simple truth, it is indeed an expression, but 
it is on your code to change the classification. If you use joins and their 
ON-clause, you will get the join columns as extra subtree.

Original comment by pho...@gmx.de on 30 Apr 2012 at 7:49

GoogleCodeExporter commented 8 years ago
no comment from reporter

Original comment by pho...@gmx.de on 2 May 2012 at 12:39