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
I am one of the developers of the C# plugin. We published our plugin in the community and received a lot of feedback - mainly around the lack of support in SQL Server.
I took a look at the engines implementations and saw that in SQLite you use antlr to parse the SQL, and that antlr has the same kind of support for tsql (SQL Server's SQL dialect).
I want to propose that I will start working on an SQL Server iplementation, in the same manner as the SQLite one. @doron050
What database engines need to be changed?
No response
What programming language backends need to be changed?
No response
Reacted by Matheus Vellone, Jakub Cytrowski, mispp, Socrates Utui, Jorge Plaza , Taísso Reni, Pablo Heredia, Tomás Wolf, Doron Eli, Brandon and 5 more
I updated the title and added the tag we use for all new engine requests. This one is unlikely to happen soon, mainly because I have larger plans for refactoring how we add new engines. That said it's most certainly on the roadmap.
What would be necessary to get some traction here? I'm doing a hard push on my org to move to more modern tooling and sqlc not being in sql server is one of the biggest detractors for a mainly microsoft shop.
@kyleconroy given that there's 2 people willing to commit their time to this, can anything about the refactor be sped up? Maybe outlining the interfaces that will be used, or have them just go ahead with it right now and deal with the refactor later?
I posted a 2026 roadmap a few days ago. While this didn't make it, the Go API should make it much easier to support SQL Server.
@twolfvb the help I need is on the research side. For SQL server support, I need to find a Go parser for T-SQL (that doesn't depend on cgo) and to document the process for extracting column and parameter information from a query using a running SQL Server.
@kyleconroy Confirming the first part regarding a GO parser for T-SQL, does using the same antlr4-grammers codegen tool done for SQLite work? Because as far as we can tell, there is no CGO dependency in that tool.
Regarding the documentation - I am famiiar with how to do that, ex-DBA and all. That part we can definitely take
We built SQL Server support for sqlc-gen-csharp on top of main and ran it against a corpus of 187 T-SQL cases, using SQL Server 2022 itself (sp_describe_undeclared_parameters / sp_describe_first_result_set) as the reference for parameter and column types.
Feeding the failing statements straight to teesql, these four are parser bugs, opened there:
Everything else the corpus hits parses fine in teesql and is a sqlc-side gap. The full report, case by case, is here, and the gaps are grouped into issue drafts here. The main ones:
statements the converter doesn't know (SET NOCOUNT ON, DECLARE, EXEC, MERGE) are silently dropped
We also carry four small patches on top of main (sqlc.arg/narg/slice/embed for mssql, a :copyfrom panic, TRUNCATE, case-insensitive @name): scripts/sqlc-patches. Happy to open them as issues/PRs if that's welcome.
Activity
[-]Support SQL Server as an engine[/-][+]Add Microsoft SQL Server support[/+]kyleconroy commentedon Jan 9, 2025
I updated the title and added the tag we use for all new engine requests. This one is unlikely to happen soon, mainly because I have larger plans for refactoring how we add new engines. That said it's most certainly on the roadmap.
twolfvb commentedon Nov 26, 2025
What would be necessary to get some traction here? I'm doing a hard push on my org to move to more modern tooling and sqlc not being in sql server is one of the biggest detractors for a mainly microsoft shop.
doron050 commentedon Nov 28, 2025
If it's possible, @SockworkOrange and I are willing to give it a try 🙏
twolfvb commentedon Nov 28, 2025
@kyleconroy given that there's 2 people willing to commit their time to this, can anything about the refactor be sped up? Maybe outlining the interfaces that will be used, or have them just go ahead with it right now and deal with the refactor later?
twolfvb commentedon Dec 10, 2025
@kyleconroy any inputs here?
kyleconroy commentedon Dec 10, 2025
I posted a 2026 roadmap a few days ago. While this didn't make it, the Go API should make it much easier to support SQL Server.
@twolfvb the help I need is on the research side. For SQL server support, I need to find a Go parser for T-SQL (that doesn't depend on cgo) and to document the process for extracting column and parameter information from a query using a running SQL Server.
SockworkOrange commentedon Dec 10, 2025
@kyleconroy Confirming the first part regarding a GO parser for T-SQL, does using the same
antlr4-grammerscodegen tool done for SQLite work? Because as far as we can tell, there is no CGO dependency in that tool.Regarding the documentation - I am famiiar with how to do that, ex-DBA and all. That part we can definitely take
kyleconroy commentedon Dec 23, 2025
I've made a first pass at a T-SQL parser here https://github.com/sqlc-dev/teesql
Please try it out! If it can't parse something, please open an issue.
kyleconroy commentedon Aug 20, 2026
Initial support for
parseandanalyzehas landed here #4571kyleconroy commentedon Oct 14, 2026
Code generation support landed in #4621. Please build from main to try it out. Feedback needed!
doron050 commentedon Oct 31, 2026
We built SQL Server support for sqlc-gen-csharp on top of
mainand ran it against a corpus of 187 T-SQL cases, using SQL Server 2022 itself (sp_describe_undeclared_parameters/sp_describe_first_result_set) as the reference for parameter and column types.Feeding the failing statements straight to teesql, these four are parser bugs, opened there:
MERGE ... USING (VALUES ...) AS alias (columns)fails to parseMESSAGEis treated as a reserved word in expressions and column lists.query()method fails to parseEverything else the corpus hits parses fine in teesql and is a sqlc-side gap. The full report, case by case, is here, and the gaps are grouped into issue drafts here. The main ones:
SET NOCOUNT ON,DECLARE,EXEC,MERGE) are silently droppedCROSS APPLY/ table-valued functions /PIVOTaren't supportedDATEADD(DAY, ...)readsDAYas a columnWe also carry four small patches on top of
main(sqlc.arg/narg/slice/embed for mssql, a:copyfrompanic,TRUNCATE, case-insensitive@name): scripts/sqlc-patches. Happy to open them as issues/PRs if that's welcome.