Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values
От | Tom Lane |
---|---|
Тема | Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values |
Дата | |
Msg-id | 4421.1502770982@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values
|
Список | pgsql-bugs |
Peter Geoghegan <pg@bowt.ie> writes: > The comments that pg_import_system_collations() adds to each locale > have an annoying tendency to exclude anything that isn't ascii-safe, Right, but that's *necessary* for anything that goes into template0. > Notice the lack of descriptions here, just because they weren't > ascii-safe. I now wonder if we should even keep the comment thing at > all. We can eventually add an SQL function, that is called by \dOS+, > that interrogates ICU for a description on the fly. Yup, the same idea came to me as I was reading your message. So we don't really want a pg_collation column either, but a function that can produce a result that varies with the current database's encoding. > Another thing that I dislike about get_icu_locale_comment() is that > the descriptions we show are always English display names, regardless > of pg_database collation or anything else. We shouldn't hard-code the > use of English for display name, on general principle. Again, that was mostly driven by the desire to get ASCII results (or at least so I imagine; Peter E. might have a different take). I think there's value in having a function that produces such a description, but we could have a different one that produces a description in the language indicated by the database's locale. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: