Context Navigation

Changes between Initial Version and Version 1 of Ticket #34840, comment 19

initial	v1
5	5	I think it makes sense to use this approach in cases where Python input poses type ambiguity at the database level like it did with the `IN` operator, after all we were forced to add `::text` cast because Postgres doesn't know what the type of `%s IS NULL` should be.
6	6
7		In all cases the adjustments to `Q.check` to handle `EmptyResultSet` should be added as other lookups could generate it, the same can be said ~~with~~ `FullResultSet`.
	7	In all cases the adjustments to `Q.check` to handle `EmptyResultSet` should be added as other lookups could generate it, the same can be said about `FullResultSet`.
8	8
9	9	I think we should not let the discussion about the silencing of `DatabaseError` die off though and consider a deprecation path to raise the awareness of the issue. Maybe a possible alternative solution that doesn't warrant expression introspection (e.g. special casing `RawSQL`) could be a `Constraint` kwarg that allows disabling model level validation entirely? That could be a way to silence the warning during the deprecation period.