Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values
От | Robert Haas |
---|---|
Тема | Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values |
Дата | |
Msg-id | CA+TgmoZXmrFu9oYbPXcDbHcDSYpZzPRm-VZc7pVoiDOiHMSGNw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values
|
Список | pgsql-bugs |
On Mon, Aug 7, 2017 at 1:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > So they added emojis (I'm with Peter G that we could do without installing > that by default) ... but what became of the af-NA and af-ZA collations? > If I were a user who'd adopted one of those as a database collation, > I'd be seriously unhappy to have them go away in a later PG release. I disagree with this argument. I think you're looking at this problem from the wrong angle. If the customer doesn't really care what collation they end up with, then filtering down the set of collations is exactly the right fix -- they'll pick something that is included rather than something that is excluded. However, I think we should assume that people choose a collation because they want and need the sorting behavior it gives. In that case, if we remove the collation from the default catalog contents, then people who need it will (1) see that it's not there, be unhappy, and give up or (2) figure out that they can create it manually, do so, and then have the same upgrade problem. In other words, excluding, say, emoji collations from what gets imported is just making a value judgement that those collations aren't important and people shouldn't want to use them. It's saying that we know better than the ICU maintainers which collations ought to exist. To use one of your phrases, color me skeptical. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 по дате отправления: