iffyio commented on code in PR #1979:
URL:
https://github.com/apache/datafusion-sqlparser-rs/pull/1979#discussion_r2242324524
##########
src/dialect/mod.rs:
##########
@@ -841,6 +841,12 @@ pub trait Dialect: Debug + Any {
false
}
+ /// Returns true if this dialect allow colon placeholders
+ /// e.g. `SELECT :var` (JPA named parameters)
+ fn supports_colon_placeholder(&self) -> bool {
+ false
+ }
Review Comment:
Yeah that's correct that the input would be stripped into two, the kind and
the value as in your examples.
`Value::Placeholder` I imagine would have the same representation mirroring
`Token::Placeholder` since the goal becomes that placeholder parsing is handled
by the tokenizer i.e.`Value::Placeholder(Token::Placeholder)`
> which, naturally, is never None or empty
I think we might not always have a variable name, hence the `Option` -
sqlite for example uses anonymous `?` in some contexts for placeholders e.g.
`WHERE city IN (?, ?, ?, ?)`. In that scenario the representation becomes
`Token::Placeholder{kind: PlaceholderKind::SingleQuestionMark, value: None}`
> value: String, // ~ preferrably &'a str
ah heads up I think a reference `&str` wouldn't be feasible here without
introducing lifetimes to the Token/Value enums which would be quite an invasive
change and likely not worth it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
