Very interesting. But is the sort overhead worth it? Why not make the
constraint deferrable before the update and switch back afterwards?
I've just read Laurenz' blog post about the differences between Oracle
and PostgreSQL[1].
One of the differences is that something like
UPDATE tab SET id = id + 1;
tends to fail on PostgreSQL because the the primary key constraint is
checked for every row, so it will stumble over the tempora
On 2025-04-20 11:34:56 +0200, Thiemo Kellner wrote:
> Very interesting. But is the sort overhead worth it? Why not make the
> constraint deferrable before the update and switch back afterwards?
Mostly idle curiosity whether that's possible at all.
But there might be other reasons why you want to
Hm, deadlocks preventing order by. Never had that problem. Then again, I mostly
have Oracle experience and no need for complicated updates. If I had, I'd
rather think of chunking updates and orchestrate those before ordering within
updates.
On Sun, Apr 20, 2025 at 5:35 AM Thiemo Kellner
wrote:
> Very interesting. But is the sort overhead worth it? Why not make the
> constraint deferrable before the update and switch back afterwards?
>
The role which runs the UPDATE might not have the priv to ALTER TABLE ...
ALTER CONSTRAINT.
--
D
Might that be a feature of or a flaw in the application design? I opt for the
latter. Any application that needs updates, be it only in emergency cases,
should take that into account.
On 4/20/25 02:10, Peter J. Holzer wrote:
I've just read Laurenz' blog post about the differences between Oracle
and PostgreSQL[1].
One of the differences is that something like
UPDATE tab SET id = id + 1;
tends to fail on PostgreSQL because the the primary key constraint is
checked for ev
