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

Peter Geoghegan <pg@bowt.ie> writes:
> On Mon, Aug 14, 2017 at 12:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Maybe I'm missing something, but I didn't think there would be anything
>> terribly disastrous about having pg_import_system_collations() install
>> these descriptions as comments in v10 and then changing it to put them
>> directly into pg_collation in later versions.  We'd have to adapt the
>> behavior of psql's \dO, but that's true no matter when we change that.

> Well, I don't think you're going to get on board with the idea of
> having CREATE COLLATION add a comment (and I agree that that's a bad
> idea), so CREATE COLLATION is in a very bad spot if we put this off
> for a release.

How so?  When you create the collation in v11, the column will get
populated, no problem.  (I'm envisioning that we add code to CREATE
COLLATION to populate it, much as Peter E's auto_comment patch did
except for where the data goes.)

> Unless we add an ICU-owned pg_collation column for the human-readable
> ICU string, CREATE COLLATION will not let the user determine what ICU
> thinks the collation/language is from within Postgres.

Somehow, this does not strike me as a stop-ship problem for v10.
It's a nice-to-have feature, sure, but we're past the time for that.
For now, we have to take the attitude that it's the user's problem
whether the arguments for CREATE COLLATION are sane --- we can blame
that policy on ICU itself.

(BTW, I would argue vehemently against defining this new column as
"ICU owned".  I think it should just be "colldescription" and we
populate it with whatever is reasonable.  For example we can move the
comments for the hardwired collations there.  I dunno whether we can
come up with anything authoritative for libc collations, but if we
can, they're welcome to the party as well.)
        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