Re: Fix optimization of foreign-key on update actions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fix optimization of foreign-key on update actions
Date
Msg-id 7151.1549383652@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fix optimization of foreign-key on update actions  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Fix optimization of foreign-key on update actions  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Peter" == Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>  Peter> The SQL standard seems clear

> (since when has the SQL standard ever been clear?)

Point to Andrew ;-).  However, I kind of like Peter's idea anyway
on the grounds that byte-wise comparison is probably faster than
invoking the datatype comparators.  Also, language lawyering aside,
I think he may be right about what people would expect "should" happen.

What I *don't* like about the proposed patch is that it installs a
new, different comparison rule for the ON UPDATE CASCADE case only.
If we were to go in this direction, I'd think we should try to use
the same comparison rule for all FK row comparisons.

The inconsistencies get messier the more you think about it,
really.  If a referencing row was datatype-equal, but not byte-equal,
to the PK row to start with, why would an update changing the PK row
(perhaps to another datatype-equal value) result in forcing the
referencing row to become byte-equal?  How does this fit in with
the fact that our notion of what uniqueness means in the PK table
is no-datatype-equality, rather than no-byte-equality?

On the whole we might be better off leaving this alone.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Fix optimization of foreign-key on update actions
Next
From: Justin Pryzby
Date:
Subject: Re: pg11.1: dsa_area could not attach to segment