Date: Mon, 1 Nov 2021 20:12:39 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: marcus@cockroachlabs.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17261: FK ON UPDATE CASCADE can break referential integrity
 with columns of different types
Message-ID: <202111012312.6uzrqejsrg5j@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1311165.1635803989@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/202111012312.6uzrqejsrg5j%40alvherre.pgsql>
Precedence: bulk

On 2021-Nov-01, Tom Lane wrote:

> PG Bug reporting form <noreply@postgresql.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/