[jitl]

If they’re gonna do that why bother making a new concept? You could already build(normalString, someDict)

Like why make me state “A goes here, also the value of A is 1” when I can just say “1 goes here”? When I build an array or map, I just write the expression

{ key1: value1 }

I don’t need to write

build({ key1, value1 }, { “key1”: key1, “value1”: value1 })

Why should an sql literal be any different from an array or dictionary literal?

[90s_dev]

Yeah in retrospect it's identical to what JavaScript does with string literals. I don't know what I was thinking.

[williamdclt]

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.

[90s_dev]

`...` 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.

[williamdclt]

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)

[90s_dev]

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.

[jitl]

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.

[90s_dev]

Oh wait I know why. It's because the PIP had no specialized syntax highlighting to show that it was getting the variables from scope. So I started reasoning about it differently than I do about JS string literals, rather lazily too, and ended up thinking of something like emacs's dynamic scope or something. Amazing what syntax highlighting does to how we think.