From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | marcus(at)cockroachlabs(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17261: FK ON UPDATE CASCADE can break referential integrity with columns of different types |
Date: | 2021-11-01 23:12:39 |
Message-ID: | 202111012312.6uzrqejsrg5j@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2021-Nov-01, Tom Lane wrote:
> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > It is possible to break foreign key referential integrity when the FK
> > columns have different types and updates are cascaded from the parent
> > relation to the child relation.
>
> I'm not really sure what you'd consider such an FK relationship to mean.
> I can't get too excited about it when there doesn't seem to be a well
> defined semantics for it.
Yeah, I was thinking that a possible fix might be to reject the creation
of such an FK, but I'm not sure what would be a good test to determine
acceptability. It's not as easy as rejecting different typmods, in
general: for example, rejecting FKs of varchars because their max
lengths are different would be inappropriate.
For numeric perhaps we could get away with saying that the referencing
column must have a scale that's at least as large as the referenced
column. But I wouldn't want to get in the business of having
type-specific rules for this, because that seems messy and
overcomplicated for little useful gain.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2021-11-01 23:14:32 | Re: BUG #17261: FK ON UPDATE CASCADE can break referential integrity with columns of different types |
Previous Message | Marcus Gartner | 2021-11-01 22:03:50 | Re: BUG #17261: FK ON UPDATE CASCADE can break referential integrity with columns of different types |