<story><title>SQLGlot: SQL parser, transpiler, optimizer – translate to Presto, Spark, Hive</title><url>https://github.com/tobymao/sqlglot</url></story><parent_chain></parent_chain><comment><author>flakiness</author><text>The parser.py [1] has only 1.6k lines. And it is hand-written parser. This size is amazing if it&amp;#x27;s really capable, but I intuitively doubt it. For example, duckdb&amp;#x27;s select.y [2] has 3700 lines, and this is only for SELECT. ZetaSQL&amp;#x27;s grammar file [3] is almost 10k lines.&lt;p&gt;The SQL is a monstrous language. Is there any trick that keeps the code simple?&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;tobymao&amp;#x2F;sqlglot&amp;#x2F;blob&amp;#x2F;main&amp;#x2F;sqlglot&amp;#x2F;parser.py&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;tobymao&amp;#x2F;sqlglot&amp;#x2F;blob&amp;#x2F;main&amp;#x2F;sqlglot&amp;#x2F;parser....&lt;/a&gt;
 [2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;duckdb&amp;#x2F;duckdb&amp;#x2F;blob&amp;#x2F;master&amp;#x2F;third_party&amp;#x2F;libpg_query&amp;#x2F;grammar&amp;#x2F;statements&amp;#x2F;select.y&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;duckdb&amp;#x2F;duckdb&amp;#x2F;blob&amp;#x2F;master&amp;#x2F;third_party&amp;#x2F;lib...&lt;/a&gt;
 [3] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;google&amp;#x2F;zetasql&amp;#x2F;blob&amp;#x2F;master&amp;#x2F;zetasql&amp;#x2F;parser&amp;#x2F;bison_parser.y&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;google&amp;#x2F;zetasql&amp;#x2F;blob&amp;#x2F;master&amp;#x2F;zetasql&amp;#x2F;parser...&lt;/a&gt;</text></comment>
<story><title>SQLGlot: SQL parser, transpiler, optimizer – translate to Presto, Spark, Hive</title><url>https://github.com/tobymao/sqlglot</url></story><parent_chain></parent_chain><comment><author>RobinL</author><text>SQLGlot is great.  We&amp;#x27;ve used it to extend our FOSS probabilistic data linking library[1] so that it is now capable of executing against a variety of SQL backends (Spark, Presto, DuckDB, Sqlite), significantly widening our potential user base.&lt;p&gt;We implement the core statistical model in SQL, and then use SQLGlot to transpile to the target execution engine.  One big motivation was to futureproof our work - we&amp;#x27;re no longer tied down to Spark, and so when the &amp;#x27;next big thing&amp;#x27; (GPU accelerated SQL for analytics?) comes along, it should be relatively straightforward to support it by writing another adaptor.&lt;p&gt;Working on this has highlighted some of the really tricky problems associated with translating between SQL engines, and we haven&amp;#x27;t hit any major problems, so kudos to the author!&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;moj-analytical-services&amp;#x2F;splink&amp;#x2F;tree&amp;#x2F;splink3&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;moj-analytical-services&amp;#x2F;splink&amp;#x2F;tree&amp;#x2F;splin...&lt;/a&gt;</text></comment>