Name of variable in query seems to introduce a parse issue

Description

Code to reproduce is at [1] as well as the output I'm seeing. What I'm seeing is for two queries which are exactly the same except for name of a variable in the object position of a triple pattern produce different algebra representations; the order of the joins are reversed. Unfortunately, because they're optional joins, the alternate ordering has different semantics than the correct representation, so it seems that depending on the name of a var, I can get an incorrect algebra and thus incorrect results. The first query parses correctly producing the algebra I'd expect, the second in which the variable ?c is renamed ?var2, the join is reversed. The parse order is correct from what I can tell, the predicate has a bound value in both triple patterns, and in both cases, the predicate of the first triple pattern is named const-1, which afaiu, means it was parsed first. So I'm not sure at what point they get switched and the join ends up wrong, but it seems to happen every single time on my machine. If you use ARQ (sparql.org) to parse the query, you can see that it produces the same algebra sesame produces when it's correct. [1] https://gist.github.com/3988683

Copy-pasted examples queries:

Q1:

Q2:

Environment

None

Status

Assignee

Jeen Broekstra

Reporter

Michael Grove

Labels

None

Components

Fix versions

Affects versions

Priority

Critical
Configure