Re: Busted(?) optimization in ATAddForeignKeyConstraint

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 2020-01-23 23:11, Tom Lane wrote:
>> I happened to notice this comment in the logic in
>> ATAddForeignKeyConstraint that tries to decide if it can skip
>> revalidating a foreign-key constraint after a DDL change:
>> * Since we require that all collations share the same notion of
>> * equality (which they do, because texteq reduces to bitwise
>> * equality), we don't compare collation here.
>> Hasn't this been broken by the introduction of nondeterministic
>> collations?

> I'm not very familiar with the logic in this function, but I think this
> might be okay because the foreign-key equality comparisons are done with
> the collation of the primary key, which doesn't change here AFAICT.

If we're depending on that, we should just remove the comment and compare
the collations. Seems far less likely to break.

Even if there's a reason not to do the comparison, the comment needs
an update.

regards, tom lane