If the referencing and referenced columns have different collations,
the parser will be unable to resolve which collation to use unless it's
helped out in this way.  The effects are sometimes masked, if we end up
using a non-collation-sensitive plan; but if we do use a mergejoin
we'll see a failure, as recently noted by Robert Haas.

The SQL spec states that the referenced column's collation should be used
to resolve RI checks, so that's what we do.  Note however that we currently
don't append a COLLATE clause when writing a query that examines only the
referencing column.  If we ever support collations that have varying
notions of equality, that will have to be changed.  For the moment, though,
it's preferable to leave it off so that we can use a normal index on the
referencing column.