Re: Proposal: Add a UNIQUE NOT ENFORCED constraint

From: Jacob Jackson <jej(dot)jackson(dot)08(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: Add a UNIQUE NOT ENFORCED constraint
Date: 2026-01-08 02:18:12
Message-ID: CAAiQw3ztdVE0E5iVGrZ_eGLVoZ6EoMaB+bo6_Lfb4XdmK7fHwQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 7, 2026 at 2:12 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> Some other SQL implementations have optional implementation-specific
> modes on top of NOT ENFORCED that mean, the constraint is not enforced,
> but you can assume it holds for query planning purposes. This is
> probably what the thinking here was, but that is not how PostgreSQL
> currently works, so additional work would need to be done to add this
> additional mode.
>
> There are probably also multiple levels to this. It's one thing to use
> an unenforced-but-probably-true constraint for things like selectivity
> estimation, where you just get a worse plan if it's not quite true, but
> it's another to assume something is unique when it might not be. So
> there is some research to be done here.

Yeah, after reading through Matthias's and your comments, I am
increasingly convinced that the best option is to add a separate
trusted/untrusted flag that would decide whether Postgres allows any
query plans that could change results if the data isn't actually
unique. It seems feasible, but I haven't worked on implementing it
yet.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-01-08 02:38:58 Re: Refactor query normalization into core query jumbling
Previous Message Chao Li 2026-01-08 02:07:21 Re: Refactor replication origin state reset helpers