summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/engine/util.py
diff options
context:
space:
mode:
authorMike Bayer <mike_mp@zzzcomputing.com>2019-12-09 18:05:00 -0500
committerMike Bayer <mike_mp@zzzcomputing.com>2019-12-22 11:31:13 -0500
commit60e7034a7423955cd89d5624f8769d3804ca6d82 (patch)
tree027fd963fc073970b9ab62ae7f389e61192b1992 /lib/sqlalchemy/engine/util.py
parentc6554ac52bfb7ce9ecd30ec777ce90adfe7861d2 (diff)
downloadsqlalchemy-60e7034a7423955cd89d5624f8769d3804ca6d82.tar.gz
Use expanding IN for all literal value IN expressions
The "expanding IN" feature, which generates IN expressions at query execution time which are based on the particular parameters associated with the statement execution, is now used for all IN expressions made against lists of literal values. This allows IN expressions to be fully cacheable independently of the list of values being passed, and also includes support for empty lists. For any scenario where the IN expression contains non-literal SQL expressions, the old behavior of pre-rendering for each position in the IN is maintained. The change also completes support for expanding IN with tuples, where previously type-specific bind processors weren't taking effect. As part of this change, a more explicit separation between "literal execute" and "post compile" bound parameters is being made; as the "ansi bind rules" feature is rendering bound parameters inline, as we now support "postcompile" generically, these should be used here, however we have to render literal values at execution time even for "expanding" parameters. new test fixtures etc. are added to assert everything goes to the right place. Fixes: #4645 Change-Id: Iaa2b7bfbfaaf5b80799ee17c9b8507293cba6ed1
Diffstat (limited to 'lib/sqlalchemy/engine/util.py')
0 files changed, 0 insertions, 0 deletions