On Tue, Aug 4, 2020 at 11:42 AM Dave Page <dpage@pgadmin.org> wrote:
On Tue, Aug 4, 2020 at 10:29 AM Magnus Hagander <magnus@hagander.net> wrote:
On Tue, Aug 4, 2020 at 10:07 AM Dave Page <dpage@pgadmin.org> wrote:
On Tue, Aug 4, 2020 at 1:04 AM Bruce Momjian <bruce@momjian.us> wrote:
On Mon, Aug 3, 2020 at 08:56:06PM +0200, Daniel Verite wrote: > Hi, > > As a follow-up to bug #16570 [1] and other previous discussions > on the mailing-lists, I'm checking out PG13 beta for Windows > from: > https://www.enterprisedb.com/postgresql-early-experience > and it ships with the same obsolete ICU 53 that was used > for PG 10,11,12. > Besides not having the latest Unicode features and fixes, ICU 53 > ignores the BCP 47 tags syntax in collations used as examples > in Postgres documentation, which leads to confusion and > false bug reports. > The current version is ICU 67. > > I don't see where the suggestion to upgrade it before the > next PG release should be addressed but maybe some people on > this list do know or have the leverage to make it happen?
Well, you can ask EDB about this, but perhaps the have kept the same ICU version so indexes will not need to be reindexed.
Correct - updating ICU would mean a reindex is required following any upgrade, major or minor.
I would really like to find an acceptable solution to this however as it really would be good to be able to update ICU.
It certainly couldn't and shouldn't be done in a minor.
But doing so in v13 doesn't seem entirely unreasonable, especially given that I believe we will detect the requirement to reindex thanks to the versioning, and not just start returning invalid results (like, say, with those glibc updates).
Would it be possible to have the installer even check if there are any icu indexes in the database. If there aren't, just put in the new version of icu. If there are, give the user a choice of the old version or new version and reindex?
That would require fairly large changes to the installer to allow it to login to the database server (whether that would work would be dependent on how pg_hba.conf is configured), and also assumes that the ICU ABI hasn't changed between releases. It would also require some hacky renaming of DLLs, as they have the version number in them.
I assumed it had code for that stuff already. Mainly because I assumed it supported doing pg_upgrade, which requires similar things no?
The chances of designing, building and testing that thoroughly before v13 is released is about zero I'd say.
Yeah, I can see how it would be for 13 -- unfortunately. But I definitely think it's something that should go high on the list of things to get fixed for 14.
