sql-formatter
sql-formatter copied to clipboard
sql-formatter-org
Feature Request: Add Snowflake as a SQL Dialect
Describe the Feature
The sql-formatter currently supports many SQL dialects, including BigQuery and SQL Server. Would it be possible to add Snowflake?
Why do you want this feature?
I use Snowflake. I am particularly interested in whether the auto-formatter provided from the open source code by Snowflake, GitHub - Snowflake-Labs/snowsql-formatter, is materially different (in whether it will produce compilation errors) from what is provided here by sql-formatter.
Duplicate of #173 I'll make note of the consistent interest of adding Snowflake as a supported dialect.
As for the differences between this upstream library and snowsql-formatter, this package has had several major revisions across all parts of the codebase in the past 6-12months so I would definitely recommend using this package if it works for your use cases.
We would gladly accept a PR for Snowflake as a new language if you feel up to it, please feel free to reach out to me or @nene for assistance - the main effort there would be to research/document the syntax (ie. special keywords, supported operators, string types, etc.)
Great, #297 is a good example of a PR with a recently added language (Trino) so you can reference that to see what changes are needed
Question:
For some Languages you have split the functions in categories: https://github.com/sql-formatter-org/sql-formatter/blob/master/src/languages/plsql/plsql.functions.ts#L5 (numeric, character, .etc.)
For others there is only a single category: https://github.com/sql-formatter-org/sql-formatter/blob/master/src/languages/trino/trino.functions.ts#L10 (all)
What is preferred here?
Snowflake offers categories for functions as well, however some functions belong to multiple categories. (see https://docs.snowflake.com/en/sql-reference/functions-all.html , have a look at the Category column). What should be done in these cases if wemove with seperate categories?
The main reason for grouping or not grouping is to make it easier to compare with language documentation. Like when official docs of an SQL dialect have functions listed in groups, it would also be better to list them in groups in the functions list. Duplicates don't matter, the flatKeywordList() function eliminates duplicates.
And when the official docs provide a simple alphabetic list of functions, it would be better to not group the functions.
