| Age | Commit message (Collapse) | Author |
|
get_placeholder_sql.
The lack of ability of the get_placeholder call chain to return SQL and
parameters separated so they can be mogrified by the backend at execution time
forced implementations to dangerously interpolate potentially user controlled
values.
The get_placeholder_sql name was chosen due to its proximity to the previous
method, but other options such as Field.as_sql were considered but ultimately
rejected due to its different input signature compared to Expression.as_sql
that might have lead to confusion.
There is a lot of overlap between what Field.get_db_prep_value and
get_placeholder_sql do but folding the latter in the former would require
changing its return signature to return expression which is a way more invasive
change than what is proposed here.
Given we always call get_db_prep_value it might still be an avenue worth
exploring in the future to offer a publicly documented interface to allow field
to take an active part in the compilation chain.
Thanks Jacob for the review.
|
|
Regression in a16eedcf9c69d8a11d94cac1811018c5b996d491.
The UNNEST strategy is affected by the same problem bulk_update has wrt/
to silent data truncation due to its usage of db_type which always returns
a parametrized subtype.
|
|
This is also applicable on CockroachDB.
|
|
column aliases on PostgreSQL.
Follow-up to CVE-2025-57833.
Thanks Stackered for the report, and Simon Charette and Mariusz Felisiak
for the reviews.
|
|
|
|
Added ignores relating to https://github.com/PyCQA/isort/issues/2352.
|
|
PostgreSQL.
Regression in 764af7a3d6c0b543dcf659a2c327f214da768fe4.
|
|
PostGIS.
Swapped to an allow list instead of a deny list for field types to
determine if the UNNEST optimization can be enabled to avoid further
surprises with other types that would require further specialization to
adapt.
Regression in a16eedcf9c69d8a11d94cac1811018c5b996d491.
Thanks Joshua Goodwin for the report and Sarah Boyce for the test.
|
|
The array fields opt-out heuristic failed to account for sized arrays.
Note that we keep relying on db_type as opposed to performing an ArrayField
instance check against the column's field as there could be other
implementations of model fields that use Postgres arrays to store the
optimization must be disabled for all of them.
Refs #35936.
Thanks Claude Paroz for the report and test.
|
|
This should make bulk_create significantly faster on Postgres when provided
only literal values.
Thanks James Sewell for writing about this technique, Tom Forbes for
validating the performance benefits, David Sanders and Mariusz Felisiak
for the review.
|