Re: CHECK Constraint Deferrable

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Himanshu Upadhyaya <upadhyaya(dot)himanshu(at)gmail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: CHECK Constraint Deferrable
Date: 2023-10-02 20:16:41
Message-ID: CAKFQuwYYh+S9sK4tW+sZP4Ky9OivBcayJJGSE-dXEr08ww7v7g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 2, 2023 at 12:25 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Himanshu Upadhyaya <upadhyaya(dot)himanshu(at)gmail(dot)com> writes:
> > V3 patch attached.
>
> Sorry for not weighing in on this before, but ... is this a feature
> we want at all? We are very clear in the existing docs that CHECK
> conditions must be immutable [1], and that's not something we can
> easily relax because if they are not then it's unclear when we need
> to recheck them to ensure they stay satisfied.

Agreed. I'm not sold on conforming to the standard being an appropriate
ideal here. Either we already don't because our check constraints are
immutable, or I'm missing what use case the committee had in mind when they
designed this feature. In any case, its absence doesn't seem that sorely
missed, and the OP's only actual example would require relaxing the
immutable property which I disagree with. We have deferrable triggers to
serve that posited use case.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Karl O. Pinc 2023-10-02 20:18:32 Re: Various small doc improvements; plpgsql, schemas, permissions, oidvector
Previous Message David Rowley 2023-10-02 20:11:43 Re: pg16: XX000: could not find pathkey item to sort