On 05/02/2019 17:20, Tom Lane wrote:
> 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.
That's easy to change. I had it like that in earlier versions of the
patch. I agree it would be better for consistency, but it would create
some cases where we do unnecessary extra work.
> 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?
This patch doesn't actually change the actual foreign key behavior.
Foreign keys already work like that. The patch only touches an
optimization that checks whether it's worth running the full foreign key
behavior because the change was significant enough. That shouldn't
affect the outcome. It should be the case that if you replace
RI_FKey_pk_upd_check_required() by just "return true", then nothing
user-visible changes.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services