Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>,
Daniel Verite <daniel@manitou-mail.org>,
PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-08-15T04:56:46Z
Lists: pgsql-bugs, pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes: > I take it that you're in agreement with me on > pg_import_system_collations() adding a display name as a comment -- we > should prevent that, even for v10? I'm kind of agnostic on that. I think we've established that that's not what we want for v11 and up, but it's not clear to me that the current behavior isn't an acceptable short-term answer. If there are comments in v10, and then in v11 there aren't because the data went somewhere else, what will that really break? BTW, it strikes me that a description function that produces strings in the database's language/encoding is not without gotchas. Suppose, for example, that we have a database using UTF8 while psql is using client_encoding LATIN1. If \dO calls a function that produces random non-ASCII strings, then there's a significant hazard of \dO failing altogether due to encoding conversion failure on the way to the client. That doesn't seem like it will pass muster. I'm not sure what to do instead, but this seems like a reason why there's value in plain-ASCII descriptions. regards, tom lane
Commits
-
Reject use of ucol_strcollUTF8() before ICU 53
- d6391b03b302 10.0 landed
-
Rethink behavior of pg_import_system_collations().
- 0b13b2a7712b 10.0 cited
-
Faster expression evaluation and targetlist projection.
- b8d7f053c5c2 10.0 cited