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

On Mon, Aug 14, 2017 at 1:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.)

I meant that we'd be in a bad spot for v10, at least. I suppose that
you're right that it can be corrected in v11. This doesn't seem like
the best plan, but I understand that we are short on time here.

>> 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.

I hope that we manage to slip in the minimal sanitization I described,
which doesn't need a catversion bump at all.

> (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.

Agreed. "ICU owned" was intended as an informal shorthand for
"collation provider owned".

--
Peter Geoghegan