This can be checked by expression functions which are costly to
evaluate (e.g. those which fetch features from a layer) and which
would benefit from early exits when the results of the expression
evaluation are no longer needed (e.g. due to canceling a layer
rendering, etc)
this to abort the acquisition of a connection in the OGR
connection pool
Provide a mechanism to avoid a deadlock when multiple OGR iterators
are trying to obtain a connection to a resource at once.
Refs https://github.com/qgis/QGIS/issues/43572
a few select dialogs
If the user has gone to the trouble of picking a CRS from the dialog,
it should ALWAYS be pushed to the list of recently used CRS, regardless
of whether they've done it from project properties, layer properties,
some processing algorithm, etc...
When features have a temporal "range", we should never treat
that range as inclusive of the end (or we end up with features
appearing in multiple date ranges)
Completes fixes begun by @rduivenvoorde in https://github.com/qgis/QGIS/pull/40989Fixes#38468
during preparation wherever possible
In many situations we are able to optimize a case when expression
and replace it with a simpler expression node during the preparation
stage. Specifically, if the WHEN conditions are known to be
static values (such as those coming from certain expression context
variables) then we can often replace the whole condition node
with the THEN node of the first static true condition.
E.g.
CASE
WHEN @variable=1 THEN "first_field"
WHEN @variable=2 THEN "second_field"
ELSE "third_field"
END
If @variable is static and '1', then the whole expression node will ALWAYS
be identical to "first_field". Similiarly if @variable='2', then the
whole expression will ALWAYS be "second_field".
If we're able to apply this optimization, then we use the simplified
effective node which represents the whole node during evaluation
time and save a bunch of unnecessary work.
TODO: If we use the effective node during expression compilation
for providers we would be able to handoff more expressions involving
QGIS-side variables and other components to the backend, resulting
in increased use of backend provider indices, etc....
