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
sqlparser currently accepts Postgres-style set variable = expr and Snowflake-style set (variable, other_variable) = (expr, expr) syntax. It also accepts MySQL-style set variable = expr, other_variable = expr syntax, but not in the way one might expect: other_variable = expr becomes another expression in the list of values.
This round-trips okay, and could be sufficient for many use cases if they are willing to decipher the binary operators in the expressions. However, it might be appropriate to represent this differently in the AST, along the lines of:
This could be a bit annoying to parse unless we simply switch on the dialect at the very start of parse_set (MySQL doesn't support either Postgres- or Snowflake-style assignments).
The text was updated successfully, but these errors were encountered:
sqlparser currently accepts Postgres-style
set variable = expr
and Snowflake-styleset (variable, other_variable) = (expr, expr)
syntax. It also accepts MySQL-styleset variable = expr, other_variable = expr
syntax, but not in the way one might expect:other_variable = expr
becomes another expression in the list of values.This round-trips okay, and could be sufficient for many use cases if they are willing to decipher the binary operators in the expressions. However, it might be appropriate to represent this differently in the AST, along the lines of:
This could be a bit annoying to parse unless we simply switch on the dialect at the very start of
parse_set
(MySQL doesn't support either Postgres- or Snowflake-style assignments).The text was updated successfully, but these errors were encountered: