On Fri, Sep 13, 2019 at 9:57 AM Daniel Verite <daniel@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