Looks very nice but the Absent functionality seems like a potential foot gun to me, easy to remove an entire WHERE clause and blow up a whole table! If I have a filter in sql query it's because I really want it to be used!
[deleted]
Show HN: SQL-tString a t-string SQL builder in Python
31–40 of 43 posts
Re: Show HN: SQL-tString a t-string SQL builder in Python
#32Earlier quoted context omitted.
Yeah in retrospect it's identical to what JavaScript does with string literals. I don't know what I was thinking.
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.
`...` 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.
Re: Show HN: SQL-tString a t-string SQL builder in Python
#33I think that, since you don't allow `sql(t"SELECT {a-1}")`, you should allow `sql(t"SELECT {}", a - 1)`, as long as that is possible with t-strings. This would be similar to Rust's `format!` then.
Re: Show HN: SQL-tString a t-string SQL builder in Python
#34Earlier quoted context omitted.
The presence of Absent removes the entire expression, and if that removal results in an empty clause (or group) it will remove that as well. For example if `a = Absent` `WHERE a = {a}` will remove everything, whereas `WHERE a = {a} AND b = {b}` will result in `WHERE b = {b}`. > Do you support templating a sql tstring into an sql tstring for composition? Yep
How do you know what the expression is though? Don’t you need to be parsing the SQL? If I have non standard SQL somewhere upstream in the text how does the parser cope?
It does parse the SQL. At the moment an expression is defined as all the text between the appropriate separators given the clause.
Re: Show HN: SQL-tString a t-string SQL builder in Python
#35I think that, since you don't allow `sql(t"SELECT {a-1}")`, you should allow `sql(t"SELECT {}", a - 1)`, as long as that is possible with t-strings. This would be similar to Rust's `format!` then.
Ah, apparently with real t-strings, `t"SELECT {a-1}"` should be allowed while `t"SELECT {}"` is not.
Here is Python master branch:
Python 3.15.0a0 (heads/main:ea2d707bd5, May 16 2025, 12:20:56) [Clang 16.0.0 (clang-1600.0.26.6)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> t"Hello {a}"
Traceback (most recent call last):
File "", line 1, in
t"Hello {a}"
^
NameError: name 'a' is not defined
>>> a=3
>>> t"Hello {a+5}"
Template(strings=('Hello ', ''), interpolations=(Interpolation(8, 'a+5', None, ''),))
>>> t"Hello {}"
File "", line 1
t"Hello {}"
^
SyntaxError: t-string: valid expression required before '}'Re: Show HN: SQL-tString a t-string SQL builder in Python
#36Earlier quoted context omitted.
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.
`...` 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.
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)
Re: Show HN: SQL-tString a t-string SQL builder in Python
#37Earlier quoted context omitted.
`...` 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.
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.
Re: Show HN: SQL-tString a t-string SQL builder in Python
#38I had a question about dynamic query fragments: is there a recommended way to compose larger queries from smaller pieces while preserving placeholder safety and avoiding manual string concatenation? For example, conditionally building WHERE clauses or joins from pre-defined fragments?
Re: Show HN: SQL-tString a t-string SQL builder in Python
#39I'm author of sqlbind[1] and since t-strings announce have been thinking really hard how to incorporate it. Like obvious cases `t"select * from table where id = {id}"` are tempting only at first glance. But simple queries could be written by other means. Dynamic ones where you should drop part of query by some condition is a real problem.
Your solution is impressive. It would be quite hard to support crazy sql extensions, for example for ClickHouse but as a concept it really ingenious.
Re: Show HN: SQL-tString a t-string SQL builder in Python
#40The columns feature seems somewhat dangerous at first glance. What if I wanted different sets of allowed columns for different parts of the query? Would I have to provide the superset of columns supported in both subqueries / tables?