Обсуждение: \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.utf8pg_catalog| aa_DJ.utf8 | aa_DJ.utf8 | aa_DJ.utf8pg_catalog | aa_ER | aa_ER |aa_ERpg_catalog | aa_ER.utf8 | aa_ER.utf8 | aa_ER.utf8pg_catalog | aa_ER.utf8@saaho | aa_ER.utf8@saaho | aa_ER.utf8@saahopg_catalog| aa_ER@saaho | aa_ER@saaho | aa_ER@saahopg_catalog | aa_ET | aa_ET | aa_ETpg_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.utf8pg_catalog| aa_DJ | aa_DJ | aa_DJpg_catalog | aa_DJ.iso88591 | aa_DJ.iso88591 | aa_DJ.iso88591pg_catalog| aa_DJ.utf8 | aa_DJ.utf8 | aa_DJ.utf8pg_catalog | aa_ER | aa_ER | aa_ERpg_catalog | aa_ER.utf8 | aa_ER.utf8 | aa_ER.utf8pg_catalog | aa_ER.utf8@saaho | aa_ER.utf8@saaho |aa_ER.utf8@saahopg_catalog | aa_ER@saaho | aa_ER@saaho | aa_ER@saahopg_catalog | aa_ET | aa_ET | aa_ETpg_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
On fre, 2011-04-08 at 20:14 -0400, Tom Lane wrote: > 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 ...) The fix you pushed looks OK. The whole way of dealing with the wrong encodings has been schizophrenic throughout the development of this feature. One idea was that at some point we could add support for creating collations in the wrong encoding in template databases, if that turns out to be something that is requested. You can, of course, do that manually already.