Peter Geoghegan <pg@bowt.ie> writes:
> On Mon, Aug 14, 2017 at 11:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That seems like a reasonable solution to me, if it's not too late
>> for another catversion bump. I like it better than the auto-comment
>> thing Peter E. suggests nearby.
> Another advantage of doing a catversion bump for v10 is that it lets
> us add a new SQL-callable function (or two). I would like to add a
> function to solve some of our discoverability problems around variant
> collations. We now agree that we should not add variants at initdb
> time, but Peter E's concern about where that leaves the
> discoverability of the variants (phonebook, emoji, pinyin, and so on)
> is a concern that I share.
> Similarly, it would also be helpful if users could inquire about both
> ICU version, and the corresponding CLDR version, using a new view.
> That way, they could easily find the right CLDR version/standard,
> which is where all the customization stuff is actually documented.
Hmm ... this all seems like good stuff, but it also seems like new
development, and it's way too late in the v10 cycle for any significant
amount of that.
My view of the state of our ICU support is that in v10, only brave
early adopters are going to be messing with it; it's not going to be
production-grade for most people for another release or three. That
being the case, I don't think that whether second-order options have
discoverability problems is really a critical concern right now.
I think at this point I'd vote to drop auto-installation of keyword
variants, and I would also vote against Peter's auto_comment proposal.
We shouldn't be adding features that we're going to supersede in v11.
Maybe, if people are okay with a catversion bump this late, we could
push the ICU descriptions into pg_collation proper, but I think it
would be fine to leave pg_import_system_collations's behavior in that
regard alone for v10, too.
As for new functions, views, etc, that's all excellent v11 material.
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
