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
Hello,
given the breadth of the parser, it would be nice if it would be possible to selectively enable features on an opt-in basis.
Let's imagine an application where only a subset of SQL is supported. In this case, the application would need to check for every possible unsupported feature manually (e.g. if I don't support windowing in queries, I would need to check if the named_window field in the Select gets populated and abort).
It would be interesting, instead, to decide beforehand which feature set is to be supported, so that only "valid" SQL gets parsed and arrives to the application.
Thanks.
The text was updated successfully, but these errors were encountered:
Setting the granularity at the keyword level, maybe we can try to modify the define_keyboard macro and the parse* functions so that they return false (not matching) when a keyword is disabled by configuration.
Hello,
given the breadth of the parser, it would be nice if it would be possible to selectively enable features on an opt-in basis.
Let's imagine an application where only a subset of SQL is supported. In this case, the application would need to check for every possible unsupported feature manually (e.g. if I don't support windowing in queries, I would need to check if the
named_window
field in theSelect
gets populated and abort).It would be interesting, instead, to decide beforehand which feature set is to be supported, so that only "valid" SQL gets parsed and arrives to the application.
Thanks.
The text was updated successfully, but these errors were encountered: