We alias where expressions to predicate, in part because where is a reserved keyword in rust.
The PathElement does not follow this pattern.
We should make the behavior consistent. For now I've only commited the change to add the missing alias. Do note this means a change in the expected payload, so we'll need to update schemas and tests too.
Before I do that, I'd like us to consider 3 different approaches and make a descision:
Preserve the status quo, making things consistent. The expected json key would be where, and for rust the key is alliased to predicate
Change all rust keys to r#where. This is the standard way to get around reserved keywords, and would make it clear from the struct keys what the expected IR looks like. The IR would still expect the keys to be where
Change all keys to be predicate, in both the rust SDK and the IR. This is the most disruptive.
I'm ambivalent about either option 2 or 3, but dislike option 1.
We alias
where
expressions topredicate
, in part becausewhere
is a reserved keyword in rust.The
PathElement
does not follow this pattern. We should make the behavior consistent. For now I've only commited the change to add the missing alias. Do note this means a change in the expected payload, so we'll need to update schemas and tests too.Before I do that, I'd like us to consider 3 different approaches and make a descision:
where
, and for rust the key is alliased topredicate
r#where
. This is the standard way to get around reserved keywords, and would make it clear from the struct keys what the expected IR looks like. The IR would still expect the keys to bewhere
predicate
, in both the rust SDK and the IR. This is the most disruptive.I'm ambivalent about either option 2 or 3, but dislike option 1.