Re: Mutable foreign key constraints

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: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Mutable foreign key constraints
Date: 2024-09-12 21:59:00
Message-ID: CAKFQuwaqYvXTqc8JrY6bnm77zBMMYXZv3xE5Ef1bDr3nNsuvaQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, September 12, 2024, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>
> A possible objection is that if anybody has such a setup and
> hasn't noticed a problem because they never change their
> timezone setting, they might not appreciate us breaking it.
> So I certainly wouldn't propose back-patching this. But
> maybe we should add it as a foot-gun defense going forward.
>

I’m disinclined to begin enforcing this. If they got a volatile data type
in a key column and don’t attempt to index the key, which would fail on the
volatile side, I’d be mighty surprised. I don’t really have much sympathy
for anyone who got themselves into the described position but I don’t see
this unsafe enough to force a potentially large table rewrite on those that
managed to build a fragile but functioning model.

I suggest adding the commentary and queries used to check for just such a
situation to the “don’t do this page” of the wiki and there just explain
while allowed for backward compatibility it is definitely not a recommended
setup.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-09-12 22:23:45 Re: Mutable foreign key constraints
Previous Message Robert Pang 2024-09-12 21:55:49 Re: AIO v2.0