The `sql_context` feature is meant to protect against SQL injection. I think for your usecase you would need to supply all columns, but you could used nested t-strings included based on whatever logic you need.
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?
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?
> SQLGlot is a no-dependency SQL parser, transpiler, optimizer, and engine [written in Python]. It can be used to format SQL or translate between 24 different dialects like DuckDB, Presto / Trino, Spark / Databricks, Snowflake, and BigQuery. It aims to read a wide variety of SQL inputs and output syntactically and semantically correct SQL in the targeted dialects.
If leaky bucket means "manages burst sizes and burst intervals" then yeah, they are similar in that regard but they do it differently. GCRA is more analogous to a traffic light where its solely time-based and there is no overhead needed to remove/add tokens so you are storing 1 less state object. For all purposes its probably a micro-optimization but being aware how GCRA works can yield less code but perhaps at the expense of obscurity of a lesser known algo.
I think you understand the differences but I think its improper to consider it a variant of leaky bucket as various resources refute