3 ms·
Interesting that this gets treated as a prepared statement. I wonder if it might have the drawback, among less experienced developers, of encouraging the use of
by mypalmike 5y ago
Interesting that this gets treated as a prepared statement. I wonder if it might have the drawback, among less experienced developers, of encouraging the use of simple string substitution in queries because it looks so much like that's what's happening.
- nerdponx 5y agoPossibly. In my experience, newbies use string interpolation because don't even know that parameterized queries exist. Once they know about it and why it's important, they generally start using it without hesitation. For everyone else, I think "tagged" string literals in general are a great compromise. You don't have to add extra syntax to the language (no need for regex literals like /^foo/ if you can write something like regex"^foo"), but you can statically signal to your dev tools that the string might require highlighting or other analysis. The downside is that you are passing around a string and not an AST or something comparable if you really do need to do complicated code generation type of work, but maybe the ideal world is to have both tagged string literals and an abstract representation. The prepared statement technique I think is used in Python as well, at least in the SQLite library (maybe the ODBC library as well). Whereas e.g. libpq has an API function for executing a query with parameters. So the Postgres version of this wouldn't return a prepared statement, but some kind of opaque object that specifies what exactly will be fed to libpq upon query execution.