\dO versus collations for other encodings

I've noticed that psql's \dO command for showing collations is a bit
schizophrenic about whether it shows entries for collations that are
irrelevant in the current database (because they use a different
encoding). For example:

regression=# \dOS aa*
List of collations
Schema | Name | Collate | Ctype
------------+------------------+------------------+------------------
pg_catalog | aa_DJ | aa_DJ.utf8 | aa_DJ.utf8
pg_catalog | aa_DJ.utf8 | aa_DJ.utf8 | aa_DJ.utf8
pg_catalog | aa_ER | aa_ER | aa_ER
pg_catalog | aa_ER.utf8 | aa_ER.utf8 | aa_ER.utf8
pg_catalog | aa_ER.utf8@saaho | aa_ER.utf8@saaho | aa_ER.utf8@saaho
pg_catalog | aa_ER@saaho | aa_ER@saaho | aa_ER@saaho
pg_catalog | aa_ET | aa_ET | aa_ET
pg_catalog | aa_ET.utf8 | aa_ET.utf8 | aa_ET.utf8
(8 rows)

regression=# \dOS pg_catalog.aa*
List of collations
Schema | Name | Collate | Ctype
------------+------------------+------------------+------------------
pg_catalog | aa_DJ | aa_DJ.utf8 | aa_DJ.utf8
pg_catalog | aa_DJ | aa_DJ | aa_DJ
pg_catalog | aa_DJ.iso88591 | aa_DJ.iso88591 | aa_DJ.iso88591
pg_catalog | aa_DJ.utf8 | aa_DJ.utf8 | aa_DJ.utf8
pg_catalog | aa_ER | aa_ER | aa_ER
pg_catalog | aa_ER.utf8 | aa_ER.utf8 | aa_ER.utf8
pg_catalog | aa_ER.utf8@saaho | aa_ER.utf8@saaho | aa_ER.utf8@saaho
pg_catalog | aa_ER@saaho | aa_ER@saaho | aa_ER@saaho
pg_catalog | aa_ET | aa_ET | aa_ET
pg_catalog | aa_ET.utf8 | aa_ET.utf8 | aa_ET.utf8
(10 rows)

The second display is including collations that are not actually
available for use in this database. The reason for the weird
discrepancy is that processSQLNamePattern is making use of
pg_collation_is_visible() in the first case but not the second,
and pg_collation_is_visible() rejects incompatible collations
(cf CollationGetCollid).

Given that this display doesn't include any encoding column, I'm
thinking that the intention was to show only relevant collation entries.
Which we could do by adding a WHERE clause about the encoding.
If the intention was to not restrict that way, don't we need an encoding
column? (But I'm not actually sure how we could make that work
unsurprisingly without changes in CollationGetCollid, which would likely
break other things, so I don't really want to hear suggestions that we
should do it the other way ...)

regards, tom lane