> 26 nov 2014 kl. 10:36 skrev Jakob Egger <ja...@eggerapps.at>: > >> One of the >> big arguments against bringing it in then (because it worked) was that >> we'd bring in another compile time dependency that's actually larger >> than PostgreSQL itself. > > Magnus: I don't see how this is a problem as long as using ICU is *optional*. > On systems with a working strcoll there is no problem with using the stdc > functions (except that ICU might offer more collations). >
In windows, it was primarily about packaging, I believe. Mind you, this was many years ago... ;) > >> Jakob, including the patch in PostgreSQL.app seems pretty reasonable. >> There's is only a small fraction of ICU that is used, a couple of libraries >> I believe. > > Palle: The ICU libraries themselves aren't that big, but the required data > files (also packaged as a dynamic library) are big (around 25MB > uncompressed). However, I'd rather increase the download size by 30% than > ship a broken database. Bear in mind that this might alter the way indexes are built. From the top of my head, I just can't remember if this is true or not. I'm probably wrong? Magnus? You would have to try. It does change the order by to properly handle utf-8 *AND* order by becomes case insensitve. I'm not sure this is correct SQL? I know that in Oracle, this is optional (NLS_COMP=LINGUISTIC and/or NLS_SORT=BINARY_CI), and SQL Server has something similar. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
