digitalmars.D - String Interpolation: SQL revisited: Dynamic Table Names
- kdevel (16/16) Feb 23 2024 After the DIP 1036(e) discussions I am under the impression that
- Steven Schveighoffer (15/33) Feb 25 2024 This could be up to the db library to deal with. It would have to
After the DIP 1036(e) discussions I am under the impression that
with the upcoming dmd release one shall be entitled to instead
auto result = db.rows ("select id, a from b where id = ?",
id);
write
auto result = db.rows (i"select id, a from b where id = $id");
But what shall be written if the table from which the data are
selected is variable, too? E.g.
string t = "ta-ble";
:
auto result
= db.rows ("select id, a from `" ~ t ~ "` where id = ?",
id);
What if the escaping rules for table names and data are
different? Can query authors benefit from string interpolation in
this case?
Feb 23 2024
On Friday, 23 February 2024 at 23:47:47 UTC, kdevel wrote:
After the DIP 1036(e) discussions I am under the impression
that with the upcoming dmd release one shall be entitled to
instead
auto result = db.rows ("select id, a from b where id = ?",
id);
write
auto result = db.rows (i"select id, a from b where id =
$id");
But what shall be written if the table from which the data are
selected is variable, too? E.g.
string t = "ta-ble";
:
auto result
= db.rows ("select id, a from `" ~ t ~ "` where id = ?",
id);
What if the escaping rules for table names and data are
different? Can query authors benefit from string interpolation
in this case?
This could be up to the db library to deal with. It would have to
know the context of the interpolation to know whether to just
straight-replace with the given string, or to use a prepared
statement. My suggestion would be for the library to either have
a specialized syntax, or a specialized type that it considers to
be a part of the query that is runtime-decided-sql.
e.g.:
```d
RuntimeSql rsql(string data) { return RuntimeSql(data); }
...
auto result = db.rows(i"select id, a from $(t.rsql) where id =
$(id)");
```
-Steve
Feb 25 2024








Steven Schveighoffer <schveiguy gmail.com>