Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values - Mailing list pgsql-bugs

From Tom Lane
Subject Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values
Date
Msg-id 5657.1502773006@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values
List pgsql-bugs
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


-- 
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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values
Next
From: Peter Geoghegan
Date:
Subject: Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values