snowflake-cloud-data-platform

Exactly what dialect of SQL does snowflake support

I get that Snowflake has it's own extensions to ANSI SQL such as UNDROP.

However, I would like to know what "dialect" (for want of a better word of SQL) does Snowflake use ?

I read in the docs:

Snowflake supports standard SQL, including a subset of ANSI SQL:1999 and the SQL:2003 analytic extensions https://docs.snowflake.com/en/user-guide/querying.html

So, is the SQL that Snowflake uses recognised anywhere ? I am wondering about the situation when I have a SQL syntax problem and I want to post here on stackoverflow. Do I use tag:snowflake-sql which seems to be just a synonymn for snowflake-cloud-data-platform or is there another SQL-related tag on stackoverflow that I should use ? Obviously I want to get the best SQL-specific answers so I don't want to limit the tags too much if possible.

Is there a list of differences anywhere between ANSI SQL:1999, SQL:2003 and Snowflake ?

Solution

  • Just like every DB they support 90% of of Standard X and +10% different because it's cheap for them to do so, or it allows exposing the underlying conceptual framing the DB is expressed in.

    Which really means there is "no standard" that captures "what they do".

    A different question might be to flip that on its head and ask "why does one want a standard".

    For the case of the post here snowflake-cloud-data-platform is the current accept tag. As long as you don't have too many generic sql or other DB-specific tags used, using any SQL that runs on Snowflake, is acceptable.

    Many people, like Gordan, will give answers in standard ANSI SQL and those answers are wonderful, but can sometimes be expressed in a more dense form given snowflakes less rigid expression tree rules.

    The other reason to want to know about standards is the classic, "we want to write standard SQL so we can move later" to which I often think, you should write the fastest performing SQL you can express, and move providers and re-express the intentions in the new DB instead of running poorly optimized "run anywhere" SQL that costs 30% more each and every month, because in 4 years time there might be a 6 month DB move project.