diesel-rs/diesel

Outcome Running diesel print-schema --schema diesel_name_probe for the PostgreSQL table diesel_name_probe."work items" produces a schema that compiles, but its native Diesel query targets "diesel_name_probe"."diesel_name_probe.work items". PostgreSQL rejects that relation. Generated queries should target "diesel_name_probe"."work items". Versions Rust stable: rustc 1.98.1 (48a229cea 2026-09-01). Diesel and installed Diesel CLI: 2.3.13; diesel_derives 2.3.10. Diesel features: default features plus postgres. PostgreSQL: 17.11. OS: Ubuntu 26.04.1 LTS, x86_64 Linux. Steps to reproduce Create this ordinary fixture in a disposable PostgreSQL database: CREATE SCHEMA diesel_name_probe; CREATE TABLE diesel_name_probe."work items" ( id bigint PRIMARY KEY, label text NOT NULL ); INSERT INTO diesel_name_probe."work items" VALUES (1, 'native fixture'); With an otherwise empty [print_schema] configuration, run: diesel print-schema --schema diesel_name_probe The installed CLI actually emits

Rust Version 1.99.0 Diesel Version 2.3.13 Diesel Features n/a Database Version MySQL 26.7 Operating System Version macOS Sequoia 15.5 What happened? Two Diesel tests that pass with MySQL 8.4 fail with MySQL 26.7: diesel_tests::integration_tests cast::infallible_cast::text_to_datetime diesel_tests::integration_tests cast::infallible_cast::time_to_text What did you expect to happen? I expected the tests to pass. Additional details The failures may be related to the chrono::NaiveTime handling in 2.3.12: https://github.com/diesel-rs/diesel/blob/main/CHANGELOG.md#2312-2026-08-07 This was originally discussed in #5261. Steps to reproduce % docker container stop diesel.mysql % docker container remove diesel.mysql % docker run -d --name diesel.mysql -p 3306:3306 -e MYSQL_ALLOW_EMPTY_PASSWORD=true mysql:26.7 % echo 'CREATE DATABASE diesel_test; CREATE DATABASE diesel_unit_test;' | docker exec -i diesel.mysql mysql % cargo xtask run-tests mysql --no-doc-tests -- --no-fail-fast # Truncated Summ

Rust Version 1.98.1 Diesel Version 2.3.13 Diesel Features postgres Database Version PostgreSQL 18.6 Operating System Version CachyOS What happened? The following query does not compile: let entity_ids = vec![1, 2, 3, 4]; incidents::table.select(incidents::id).filter(not(exists( entities::table .select(entities::id) .filter(entities::id.eq_any(entity_ids)) .except_all( alerts::table .inner_join(alerts_entities::table) .filter(alerts::incident_id.eq(incidents::id)) // compiles if I remove this line .select(alerts_entities::entity_id), ), ))); It is a conversion attempt from the following query in PostgreSQL: WITH incoming(entity_id) AS ( VALUES (1), (2), (3), (4) ) SELECT i.id FROM incidents i WHERE NOT EXISTS ( ( SELECT entity_id FROM incoming EXCEPT SELECT ae.entity_id FROM alerts a JOIN alerts_entities ae ON ae.alert_id = a.id

#5207, #5210, #5211 and #5212 added a fuzzing setup to diesel. This includes a basic corpus set. To get better results we would like to optimize the included corpus to better cover actual data. For binary database response values this means dumping at least one example for each type, better more covering all possible edge cases

Rust Version 1.90.0 Diesel Version Current main (85c79215, version 2.3.13) Diesel Features Not feature-specific. Additional affected types exist behind features such as r2d2. Database Version Not database-specific Operating System Version Not OS-specific What happened? Several error types across the Diesel workspace wrap underlying errors but do not represent those errors consistently through std::error::Error::source(). There are two related patterns: Some wrappers render the underlying error through Display, but expose it only through the deprecated Error::cause() or do not expose it at all. Modern chain-aware reporters therefore cannot traverse the complete error chain. Some wrappers render the underlying error through Display and also return it from source(). Chain-aware reporters can then print the same underlying message twice. A preliminary audit found the following affected types: diesel::result::Error InvalidCString QueryBuilderError DeserializationError SerializationE