Re: Fix optimization of foreign-key on update actions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fix optimization of foreign-key on update actions
Дата
Msg-id 7151.1549383652@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fix optimization of foreign-key on update actions  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Ответы Re: Fix optimization of foreign-key on update actions  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: Fix optimization of foreign-key on update actions
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: pg11.1: dsa_area could not attach to segment