3 ms·

Assuming you also need to format non-values in the SQL (e.g. column names), how does the `execute` function is supposed to make the difference between stuff tha

Assuming you also need to format non-values in the SQL (e.g. column names), how does the `execute` function is supposed to make the difference between stuff that should be formatted in the string vs a parametrized value?

masklinn 1y ago
Same as currently: the library provides some sort of `Identifier` wrapper you can apply to those.
- NewEntryHN 1y ago
  Fair enough. It would be nice if Python allowed to customize the formatting options after `:` This way you could encode such identifier directly in the t-string variable rather than with some "out-of-band" logic.
  - mcintyre1994 1y ago
    The article does mention that the function receiving the template has access to those formatting options for each interpolation, so presumably you could abuse the ones that are available for that purpose?
  - masklinn 1y ago
    > Fair enough. It would be nice if Python allowed to customize the formatting options after `:` It does, the `Interpolation` object contains an arbitrary `format_spec` string: https://peps.python.org/pep-0750/#the-interpolation-type https://peps.python.org/pep-0750/#the-interpolation-type However I think using the format spec that way would be dubious and risky, because it makes the sink responsible for whitelisting values, and that means any processing between the source and sink becomes a major risk. It's the same issue as HTML templates providing `raw` output, now you have to know to audit any modification to the upstream values which end there, which is a lot harder to do than when "raw markup" values are reified. > rather than with some "out-of-band" logic. It's the opposite, moving it to the format spec is out of band because it's not attached to values, it just says "whatever value is here is safe", which is generally not true. Unless you use the format spec as a way to signal that a term should use identifier escaping rules rather than value escaping rules (something only the sink knows), and an `Identifier` wrapper remains a way to bypass that.
    - pphysch 1y ago
      > Unless you use the format spec as a way to signal that a term should use identifier escaping rules rather than value escaping rules (something only the sink knows) This should be quiet common in the SQL applications. It will be nice to write t"select {name:id} from {table:id} where age={age}" and be confident that the SQL will be formatted correctly, with interpolations defaulting to (safe) literal values.

masklinn 1y ago

Same as currently: the library provides some sort of `Identifier` wrapper you can apply to those.

NewEntryHN 1y ago
Fair enough. It would be nice if Python allowed to customize the formatting options after `:` This way you could encode such identifier directly in the t-string variable rather than with some "out-of-band" logic.
- mcintyre1994 1y ago
  The article does mention that the function receiving the template has access to those formatting options for each interpolation, so presumably you could abuse the ones that are available for that purpose?
- masklinn 1y ago
  > Fair enough. It would be nice if Python allowed to customize the formatting options after `:` It does, the `Interpolation` object contains an arbitrary `format_spec` string: https://peps.python.org/pep-0750/#the-interpolation-type https://peps.python.org/pep-0750/#the-interpolation-type However I think using the format spec that way would be dubious and risky, because it makes the sink responsible for whitelisting values, and that means any processing between the source and sink becomes a major risk. It's the same issue as HTML templates providing `raw` output, now you have to know to audit any modification to the upstream values which end there, which is a lot harder to do than when "raw markup" values are reified. > rather than with some "out-of-band" logic. It's the opposite, moving it to the format spec is out of band because it's not attached to values, it just says "whatever value is here is safe", which is generally not true. Unless you use the format spec as a way to signal that a term should use identifier escaping rules rather than value escaping rules (something only the sink knows), and an `Identifier` wrapper remains a way to bypass that.
  - pphysch 1y ago
    > Unless you use the format spec as a way to signal that a term should use identifier escaping rules rather than value escaping rules (something only the sink knows) This should be quiet common in the SQL applications. It will be nice to write t"select {name:id} from {table:id} where age={age}" and be confident that the SQL will be formatted correctly, with interpolations defaulting to (safe) literal values.