From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
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 22:23:45 |
Message-ID: | 4168208.1726179825@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> 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.
Um, neither type is "volatile" and each can be indexed just fine.
It's the cross-type comparison required by the FK that brings the
hazard.
> 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.
Yeah, that's a possible approach.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-09-12 22:34:21 | Re: Switch PgStat_HashKey.objoid from Oid to uint64 |
Previous Message | David G. Johnston | 2024-09-12 21:59:00 | Re: Mutable foreign key constraints |