> Even so, applications should not rely on a NOT NULL constraint in the schema to ensure that a pazResult[] value is never NULL. An attacker might change the schema of the database, without the application knowing it, to remove the NOT NULL constraint, for example. It does not require a corrupt database to cause the problems in GDAL - just a database with a maliciously modified schema. Right, that's why my query included a "WHERE ... IS NOT NULL" clause, hoping that it would not return NULL pasResult[] values in the column that corresponds to the IS NOT NULL where clause, even if the database was corrupted. But with the new optimization, this WHERE clause is ignored when the table schema has a NOT NULL constraint. Thanks for the feedback. No need to spend more energy on this as this is something that can be dealt on application side.