From: | Amul Sul <sulamul(at)gmail(dot)com> |
---|---|
To: | Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Joel Jacobson <joel(at)compiler(dot)org>, Alexandra Wang <alexandra(dot)wang(dot)oss(at)gmail(dot)com>, Suraj Kharage <suraj(dot)kharage(at)enterprisedb(dot)com> |
Subject: | Re: NOT ENFORCED constraint feature |
Date: | 2025-03-28 09:00:39 |
Message-ID: | CAAJ_b96tB_bcaGwa0g2XR-=Mi-GHu3N738zYFoyGXBfhP=CXSA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 27, 2025 at 7:45 PM Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2025-Mar-27, Amul Sul wrote:
>
> > On Thu, Mar 27, 2025 at 6:28 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> > > That said, is there a simpler way? Patch 0003 appears to add a lot of
> > > complexity. Could we make this simpler by saying, if you have otherwise
> > > matching constraints with different enforceability, make this an error.
> > > Then users can themselves adjust the enforceability how they want to
> > > make it match.
> >
> > We can simply discard this patch, as it still reflects the correct
> > behavior. It creates a new constraint without affecting the existing
> > constraint with differing enforceability on the child. I noticed
> > similar behavior with deferrability -- when it differs, the
> > constraints are not merged, and a new constraint is created on the
> > child. Let me know your thoughts so I can avoid squashing patch 0006.
>
> I didn't read that patch and I don't know what level of complexity we're
> talking about, but the idea of creating a second constraint beside an
> existing one itches me. I'm pretty certain most users would rather not
> end up with redundant constraints that only differ in enforceability or
> whatever other properties. I failed to realize that this was happening
> when adding FKs on partitioned tables, and I now think it was a mistake.
> (As I said in some previous thread, I'd rather have this kind of
> situation raise an error so that the user can do something about it,
> rather than silently moving ahead with a worse solution like creating a
> redundant constraint.)
>
Okay, in the attached version, I’ve added an error in
tryAttachPartitionForeignKey() if the enforceability is different.
Please have a look at the 0005 patch and let me know if it looks good.
The rest of the patches remain unchanged.
I haven’t squashed the patches because, if we decide to keep the error
and avoid further complexity, we can simply discard the 0006 patch.
Regards,
Amul
Attachment | Content-Type | Size |
---|---|---|
v20-0004-Remove-hastriggers-flag-check-before-fetching-FK.patch | application/octet-stream | 10.8 KB |
v20-0005-Add-support-for-NOT-ENFORCED-in-foreign-key-cons.patch | application/octet-stream | 67.9 KB |
v20-0006-Merge-the-parent-and-child-constraints-with-diff.patch | application/octet-stream | 30.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2025-03-28 09:02:29 | RE: Fix 035_standby_logical_decoding.pl race conditions |
Previous Message | jian he | 2025-03-28 08:50:43 | Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints |