You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Your SQL parser parses the distinct keyword (when used in the context of a list of columns being selected), but does not retain it in the purposes of the AST.
Hi @sebastian, so about the parser. It is really a very slimmed down version of SQL and not a full parser. This is because I only use the parser for some very specific cases when the database doesn't give me enough information (such as input parameter nullability). To circle back to your question:
Is this an artefact of your analyzer not needing the distinct keyword in order to do its type checking?
Yes
In other words, is this a conscious omission?
Yes and no. I just don't have any use case for the distinct keyword because using it doesn't change the static types of the query. However, if you need it for some project you are working on, I would happily accept PRs to improve the parsers and publish it as a library. Though to be honest, it is currently very far from being a full-fledged SQL parser of postgres and I doubt it will be
Your SQL parser parses the distinct keyword (when used in the context of a list of columns being selected), but does not retain it in the purposes of the AST.
As an example, take the following test where the query
is parsed into the following list of columns, losing the distinct keyword in the process:
Is this an artefact of your analyzer not needing the distinct keyword in order to do its type checking? In other words, is this a conscious omission?
The text was updated successfully, but these errors were encountered: