id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
36823	Data loss using `bulk_create()` on Django 5.2 due to Postgres `UNNEST` and explicit cast truncating	James Beith		"In Django 5.2, `bulk_create()` can use a faster strategy that inserts rows via `UNNEST` of typed arrays ([https://code.djangoproject.com/ticket/35936 feature ticket]). That strategy typically involves explicitly casting the arrays to the destination column types (e.g. `varchar(8)[]`). So if we've a model field `models.CharField(max_length=8)` then PostgreSQL explicitly casts to `varchar(n)` which is a **silent truncate** to length `n`.

Previously, in Django 5.1 which doesn't use `UNNEST`, if we use `bulk_create()` passing an instance that has a value longer than 8 characters (e.g. `""AAAABBBBC""`) for the field `models.CharField(max_length=8)` we'd get a `DataError` raised and no database row persisted. On Django 5.2, the value is truncated to `""AAAABBBB""` and the row is persisted in the database.

This truncation behaviour is a [https://www.postgresql.org/docs/current/datatype-character.html#DATATYPE-CHARACTER desired SQL behaviour]:

> However, if one explicitly casts a value to character varying(n) or character(n), then an over-length value will be truncated to n characters without raising an error. (This too is required by the SQL standard.)

Further examples can be [https://dbfiddle.uk/cdkWx9O5 seen here]."	Bug	closed	Database layer (models, ORM)	5.2	Normal	duplicate	postgres bulk create unnest		Unreviewed	0	0	0	0	0	0