django http://cgit.adnoto.dev/chango.git/atom?h=devmain 2026-06-03T20:57:18Z 2026-06-03T20:57:18Z Simon Charette charette.s@gmail.com 2025-07-06T01:19:05Z urn:sha1:4bbc27c8686f10f9556cef02dbfa9f5157fbcf56 Performance regression in 37e6c5b on SQLite. Just like MySQL, and presumably Oracle, which don't have a native boolean type and incidently store booleans in integer columns, indices on such columns cannot be used when explicit boolean literal equalities are omitted. Adapt the logic introduced by refs #32691 for MySQL to be used for all backends that don't support native boolean fields instead of special casing MySQL, SQLite, and Oracle in their own special way. Note that review of this work surfaced that SQLite's query planner also cannot make use of indices when dealing with expressions of form WHERE NOT (indexed_bool_field = false) but that's a long standing problem unrelated to the restorative work performed in this patch. Thanks Klaas van Schelven for the report. 2026-04-30T23:52:11Z Raoni Timo raoni@relume.io 2026-04-30T13:57:27Z urn:sha1:9f790ef1a0f356cf6342b5d57bbaeac35aed0d9f Setting "check" in OPTIONS["pool"] previously raised TypeError because the PostgreSQL backend always passed check= to ConnectionPool() and unpacked **pool_options on top, regardless of CONN_HEALTH_CHECKS. The user's callable now takes precedence via setdefault(); pool_options is copied first to avoid mutating the user's settings dict. 2026-03-20T20:31:25Z Aarni Koskela akx@iki.fi 2026-03-14T23:04:26Z urn:sha1:994fa7780d73f6d618dc3a03339e96b5353b4e71 Based on Daniele Varrazzo's comment in https://github.com/psycopg/psycopg/issues/1273#issuecomment-3986829769 2026-03-19T16:24:17Z Simon Charette charette.s@gmail.com 2026-02-01T22:02:49Z urn:sha1:5146449a38222dc74f8f1ba88a7a7ef681e93101 Now that user provided aliases are systematically quoted there is no need to disallow the usage of the dollar sign on Postgres. 2026-03-13T00:01:02Z Simon Charette charette.s@gmail.com 2025-11-22T18:32:34Z urn:sha1:1a8fd5cf75bf855852f6bc2f75c3da9f7b145669 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. 2026-01-18T20:26:56Z Mariusz Felisiak felisiak.mariusz@gmail.com 2026-01-18T20:26:56Z urn:sha1:6cff02078799b7c683a0d39630d49ab4fe532e7c https://github.com/psf/black/releases/tag/26.1.0 2026-01-16T14:15:53Z JaeHyuck Sa wogur981208@gmail.com 2026-01-15T13:12:48Z urn:sha1:211b63142786ea77953de4f2850961e259c5b335 2025-12-31T15:41:55Z Simon Charette charette.s@gmail.com 2025-12-23T06:25:56Z urn:sha1:d6ae2ed868e43671afc4d433c3d8f4d27f7eb555 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. 2025-12-26T20:59:10Z VIZZARD-X vigneshanandmay13@gmail.com 2025-11-22T10:27:33Z urn:sha1:da19b3897dc7c2e99b120d40322b36b4f1a09fe8 2025-12-12T16:50:36Z Lily Acorn code@lilyf.org 2025-11-20T20:10:13Z urn:sha1:e95468ed97b1c250939da316218c39dad577ba32