On Fri, Sep 13, 2019 at 9:57 AM Daniel Verite <dan...@manitou-mail.org> wrote: > An advantage of this approach is that you may execute the > function before creating the collation, instead of creating the > collation, realizing there was something wrong in your > locale/lc_collate argument, dropping the collation and trying again.
That would be really nice. I also think that the documentation is entirely inadequate in this area. https://www.postgresql.org/docs/11/collation.html#COLLATION-CREATE gives some examples, but those don't help you understand the general principles very much, and it has some links to the ICU documentation, which helps less than one might think. For example it links to http://userguide.icu-project.org/locale which describes locales like en_IE@currency=IEP and es__TRADITIONAL, but if you can figure out what all the valid possibilities are by reading that page, you are much smarter than me. Then, too, according to the PostgreSQL documentation you ought to prefer forms using the newer syntax, which looks like a bunch of dash-separated things, e.g. de-u-co-phonebk. But neither the PostgreSQL documentation itself nor either of the links to ICU included there actually describe the rules for that syntax. They just say things like 'use BCP-47', which doesn't help at all. So I am just reduced to trying a bunch of things and seeing which collations appear to behave differently when I use them. This proposal wouldn't fix the problem that I have to guess what strings to use, but at least it might be clearer when I have or have not guessed correctly. I seriously hate this stuff with a fiery passion that cannot be quenched. How does anybody manage to use software that seems to have no usable documentation and doesn't even tell whether or not you supplied it with input that it thinks is valid? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
