Comment by williamdclt 2 days ago
No I think your point is valid, and is valid in JavaScript too.
Designing the “right” approach to look like the “wrong” approach (string concatenation) is a bad idea, however cute it is.
It’s annoying that the wrong thing is the more ergonomic one, but at least it jumps out at any dev with any experience, they know what sqli risk looks like. With templated strings, it’s not so obvious anymore.
I might have misunderstood your point, but scoping isn’t related to what I’m trying to say.
What I’m saying is that, regardless of how it works, I don’t think string templating for SQL is a good idea because it looks almost exactly like string concatenation. It makes more difficult to distinguish beteeen the right approach and the wrong approach (or learn about it)
No it was me who misunderstood you. And I kind of agree. I've never been a fan of tagged template literals. It gives you no autocompletion, no type checking, no syntax highlighting, nothing. And it requires a runtime string parser. I get why people like it, and maybe it's fine if you don't need those things and don't mind the cost of runtime parsing, but I need them and I do mind.
It really does not need runtime string parsing unless you want to do some kinds of manipulation. I built Notion’s sql`…` literal and “all” it does is concat the string parts arrays and concat the argument arrays so you can pass { query: string, args: PostgresArg[] } to the database. The database is the only one who needs to parse the query string.
As for syntax highlighting, that’s available in VS Code, we auto install the appropriate extension.
`...` and fn`...` in JavaScript are just syntactic sugar for function calls, the former for array.join(...) and the latter for fn(...) so there's no issue with these utilizing the current scope since that's what all function calls do.