Re: CREATE ASSERTION: database level assertions feature

From: Joe Wildish <joe(at)lateraljoin(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marcos Magueta <maguetamarcos(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: CREATE ASSERTION: database level assertions feature
Date: 2026-02-15 21:25:37
Message-ID: 3232abf3-3b6b-b56c-5aa5-56f6d82f3e94@lateraljoin.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 14 Feb 2026, Tom Lane wrote:

> Marcos Magueta <maguetamarcos(at)gmail(dot)com> writes:
>> I would be willing to at least get started with a patch for this, but
>> before that, I want to assess the interest and thoughts on how to properly
>> implement it.
>
> Everyone who has looked at that has run away screaming. The
> consequences for performance, complexity, deadlock potential,
> etc are all horrible. There are also fun questions about
> appropriate permissions. As the spec is written, it appears
> that anyone with read permission on a table can block updates
> on that table (by creating an assertion that attempted updates
> will fail).

Oracle have introduced a new type of permission to cater for that oddity. I
can't actually remember how their permission system hangs together with respect
to schema ownership, but they allow a schema-level declaration to say whether or
not the owner of schema X can create an assertion about objects in schema Y
(this was gleaned from watching one of their dev videos on this topic).

It strikes me that that might not be granular enough, and you could perhaps
instead allow assertions to be created for only those expressions whose re-check
circumstances match you own mutation rights (as per my other reply on this
thread), but that's probably academic at this point. An alternative would be a
whole set of other permissions too, I guess.

Cheers,
-Joe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2026-02-15 21:35:35 Re: index prefetching
Previous Message Tomas Vondra 2026-02-15 21:17:05 Re: index prefetching