When adding logging via db manager to an existing layer, all the
time_start of existing features are still null. When we modify one
feature for the first time, the update trigger fires and insert a row
for the past state of the feature. In turn, this fires the INSERT
trigger for this row, and the execution goes inside the `if
NEW.time_start is NULL`, which set the end timestamp to NULL, making the
old row still visible in the _current view.
In other word, the insert trigger makes the assumption that a null start
timestamp means now, which is not true in the case described above.
This commit fixes this assumption by initially setting it to `-infinity`
for existing rows.
This reverts commit 26e9ec98e76591286576d2dde098578877bef9c0.
It results in unfixable crashes on many platforms, likely due to some
issue in sip itself
Fixes#38393, reopens#38245
The original bug (being asked twice for credentials) is preferable
over a hard crash
Fixes#38092 by adding an optional QgsFeedback argument to
the executeSql method and by implementing the PQCancel
method in the PG provider internals.
While the cancellation works well for all supported provider while
fetching results in the loop, the cancellation of a running query is now
implemented for the postgres provider connection only because the GPKG
and GDAL both rely on GDALDatasetExecuteSQL which cannot be interrupted.
This PR also introduce a few optimizations in the PG DB-Manager
code that should probably fix also other "slowness" issues that
were reported after 3.x during PG query execution.
A small UX change in th SQL dialog makes it evident to the user that
a cancellation request has been sent to the backend: the button text
is changed to "Cancellation requested, please wait..." so that for
provider connections that are not able to interrupt the running query
and must wait for the fetching loop to exit from the exeuteSql call
the user knows that something is happening and that a cancellation
request has been successfully sent.
