fix #430 by clarifying the additional escape hatch semantics

This commit is contained in:
Sean Corfield 2022-09-12 12:45:50 -07:00
parent 02d20bd78c
commit fb601c90d9
3 changed files with 9 additions and 3 deletions

View file

@ -1,7 +1,7 @@
# Changes
* 2.3.next in progress
* Address [#430](https://github.com/seancorfield/honeysql/issues/430) by treating `:'` as introducing a name that should be treating literally and not formatted as a SQL entity (which respects quoting, dot-splitting, etc); this expands the "escape hatch" introduced in [#352](https://github.com/seancorfield/honeysql/issues/352) in 2.2.868.
* Address [#430](https://github.com/seancorfield/honeysql/issues/430) by treating `:'` as introducing a name that should be treating literally and not formatted as a SQL entity (which respects quoting, dot-splitting, etc); this effectively expands the "escape hatch" introduced via [#352](https://github.com/seancorfield/honeysql/issues/352) in 2.2.868. _Note that the function context behavior formats as a SQL entity, rather than the usual SQL "keyword", whereas this new context is a literal transcription rather than as a SQL entity!_
* Address [#427](https://github.com/seancorfield/honeysql/issues/427) by adding `set-options!`.
* 2.3.928 -- 2022-09-04
@ -38,7 +38,7 @@
* 2.2.868 -- 2022-02-21
* Address [#387](https://github.com/seancorfield/honeysql/issues/387) by making the function simpler.
* Fix [#385](https://github.com/seancorfield/honeysql/issues/385) by quoting inlined UUIDs.
* Address [#352](https://github.com/seancorfield/honeysql/issues/352) by treating `:'` as introducing a function name that should not be formatted as a SQL entity (which respects quoting, dot-splitting, etc).
* Address [#352](https://github.com/seancorfield/honeysql/issues/352) by treating `:'` as introducing a function name that should be formatted as a SQL entity (which respects quoting, dot-splitting, etc), rather than as a SQL "keyword".
* 2.2.861 -- 2022-01-30
* Address [#382](https://github.com/seancorfield/honeysql/issues/382) by adding `:case-expr` for BigQuery support.

View file

@ -596,6 +596,8 @@ unless you have quoting enabled:
=> ["SELECT * FROM `foo` WHERE `my-schema`.`SomeFunction`(`bar`, ?)" 0]
```
> Note: in non-function contexts, if a keyword begins with `'`, it is transcribed into the SQL exactly as-is, with no case or character conversion at all.
### Bindable parameters
Keywords that begin with `?` are interpreted as bindable parameters:

View file

@ -152,7 +152,11 @@ The `:with-columns` clause is formatted as if `{:inline true}`
was specified so nothing is parameterized. In addition,
everything except the first element of a column description
will be uppercased (mostly to give the appearance of separating
the column name from the SQL keywords).
the column name from the SQL keywords) -- except for keywords
that with `'` which will be transcribed into the SQL exactly
as-is, with no case or character conversion at all. This
"escape hatch" is intended to allow for SQL dialects that are
case sensitive and/or have other unusual syntax constraints.
Various function-like expressions can be specified, as shown
in the example above, that allow things like `CHECK` for a