Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hole matching in parser is too greedy #4

Open
mahills opened this issue Jun 22, 2017 · 0 comments
Open

Hole matching in parser is too greedy #4

mahills opened this issue Jun 22, 2017 · 0 comments
Assignees

Comments

@mahills
Copy link
Contributor

mahills commented Jun 22, 2017

If I run the following in the SCAM2017Demo module:

rascal>showQueriesForNumberedCall(1,15);

I see the following results:

$2017-06-22T01:54:40.861+00:00$ :: Loading binary: |home:///PHPAnalysis/serialized/parsed/AddressBook-8.2.5.2.pt|
Now parsing select * from ?0 AND group_name = '?1'

rel[SQLYield yield,str queryWithHoles,SQLQuery parsed]: {<[
    staticPiece("select * from "),
    namePiece("groups_from_where"),
    staticPiece(" AND group_name = \'"),
    namePiece("to_group"),
    staticPiece("\'")
  ],"select * from ?0 AND group_name = \'?1\'",selectQuery(
    [star()],
    [hole(1)],
    noWhere(),
    noGroupBy(),
    noHaving(),
    noOrderBy(),
    noLimit(),
    [])>}
rascal>

Note that the AND group_name ... part should be in the WHERE clause. This is obviously going to be hard to parse, there is no WHERE keyword, but it may be worth putting the following text somewhere, even if it is just in a "we don't know what part of the query this is" bin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants