-
Notifications
You must be signed in to change notification settings - Fork 217
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
feat: Parse idents with *
as quoted
#1516
Conversation
fn resolve_ident_wildcard(&mut self, ident: &Ident) -> Result<Ident, String> { | ||
if ident.name != "*" { | ||
return Err("Unsupported feature: advanced wildcard column matching".to_string()); | ||
} | ||
|
||
let (mod_ident, mod_decl) = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intention with this was to do wildcard column matching:
from albums
select [a*_id]
# this selects artist_id and album_id
We'd need full knowledge of the column for that, so let's leave it for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But this feature does interfere with this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh wait, but if you use backticks, wildcard matching shouldn't be used...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To confirm, would the wildcard column matching be a PRQL or DB feature?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PRQL of course. I don't know any DB that support this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I quite dislike the idea that I'm +0. |
I can't comment on the code or the parsing implications but just to say that in #286 we discussed possibly adding a Would that not maybe make the compiler/parser code simpler? While DuckDB is quite flexible and allows You could then keep your existing identifier rules for use with
|
I see Regardless, we still have a somewhat complex system for parsing idents — I think the middle section in the issue would solve all of these, but be some work to implement. I'll merge this and have opened a new issue for that, in #1535 |
I'm not sure this is a good idea. It solves #1498 is a hacky way.
The tradeoff is that:
...needs to compile to
But:
...needs to compile to
And:
will be parsed as a namespace
schema
and a column nametable
, which then breaks.So this implements a hack where anything with
*
in gets compiled to a single ident, and so fixes the case in #1498. But the semantics are quite confusing.I think ideally — but it might be a lot of work — we would instead
from
andjoin
as namespacesfrom schema.table
would be parsed as a single namespaceschema.table
, not a namespace and columnselect table.column
would still be parsed as a namespacetable
& columncolumn
And then any ident in backticks could be opaque — we wouldn't need to split by
.
, we'd takefrom schema.table
, notfrom `schema.table`
and produce the correct thing.In the meantime, I'm +0.3 on merging this, since it solves the immediate problem.
Past discussions on this include #822 & #852