Static templates for SQL becomes a chore to express dynamic queries. A dynamic query depends from incoming request. For example search filters should add or delete conditional expressions for a query.
The issue with templates they could handle only simple cases or very specific complex static queries. Simple ones are a way easier with ORM/query builder. Highly depends from ORM though.
And a big NO-NO for me templates force you to repeat the same SQL in many slightly different queries. SQL composability is not a thing with templates.
Simple queries aren't any easier with ORM, that's the point of sqlc, you write the SQL and then call it as a function. There's no extra abstraction or added steps on top.
Repeating portions of sql isnt really an issue for me either, it's the business end of the database, you want it all there in one location, spreading it around in a composible fashion is just one abstraction too far. I know SQL, I don't want to learn anything else on top.
I guess you talk from only a Go perspective where you don't know any good ORM libraries. Other languages have quite convenient ORMs. Some allows even auto migrations, creating migration SQL for your.
Numbered parameters become fragile quite fast for even simple queries. Basically you couldn't safely use query until carefully revising a template. A template change could potentially break existing queries. It's kinda scary.
If library supports named parameters they should be used by default in examples.
Its probably to be consistent across each platform, MySQL doesn't support named queries so they are likely avoiding using them for that reason, either that or the docs are old. :)
Is the question about how to version the query? You have comments before the query that allow you to name the exported function so you could have both queries and name them something different.
Hibernate Query Language. How is it out of context?
Use Named Native Query and you have SQL queries.
I really don’t understand the objection to ORMs. By that logic, you might as well reserve a block of memory and offsets instead of class/struct attributes.
Also, SQLC doesn't allow for dynamic query building so think about an input search struct from which you may add where clauses — or not.
Also doesn't support multiple inserts with N rows being inserted.
Otherwise for standard queries, it's great.