diff --git a/doc/TODO.detail/locale b/doc/TODO.detail/locale new file mode 100644 index 0000000000000000000000000000000000000000..6c95e40b2f04cc4f98e778aaa813f35c253037a4 --- /dev/null +++ b/doc/TODO.detail/locale @@ -0,0 +1,2664 @@ +From pgsql-patches-owner+M16987@postgresql.org Thu Aug 4 17:35:52 2005 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j74LZot06577 + for ; Thu, 4 Aug 2005 17:35:50 -0400 (EDT) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id ED433529DB; + Thu, 4 Aug 2005 18:35:44 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 70225-08; Thu, 4 Aug 2005 21:35:44 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 0ECB452998; + Thu, 4 Aug 2005 18:35:44 -0300 (ADT) +X-Original-To: pgsql-patches-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id AFAF752840 + for ; Thu, 4 Aug 2005 18:33:25 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 70920-01 + for ; + Thu, 4 Aug 2005 21:33:13 +0000 (GMT) +Received: from mx-2.sollentuna.net (mx-2.sollentuna.net [195.84.163.199]) + by svr1.postgresql.org (Postfix) with ESMTP id E1C935280D + for ; Thu, 4 Aug 2005 18:33:11 -0300 (ADT) +Received: from ALGOL.sollentuna.se (janus.sollentuna.se [62.65.68.67]) + by mx-2.sollentuna.net (Postfix) with ESMTP id 7F5A08F289 + for ; Thu, 4 Aug 2005 23:33:13 +0200 (CEST) +content-class: urn:content-classes:message +MIME-Version: 1.0 +Content-Type: multipart/mixed; + boundary="----_=_NextPart_001_01C5993C.1E1CB100" +Subject: [PATCHES] FW: Win32 unicode vs ICU +X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 +Date: Thu, 4 Aug 2005 23:33:12 +0200 +Message-ID: <6BCB9D8A16AC4241919521715F4D8BCE094656@algol.sollentuna.se> +X-MS-Has-Attach: yes +Thread-Topic: Win32 unicode vs ICU +Thread-Index: AcWVyKf6M9GrCqZAQGeSvCZNg9n/jgDc1WwQ +From: "Magnus Hagander" +To: "PostgreSQL-patches" +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-patches +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-patches-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +Status: ORr + +This is a multi-part message in MIME format. + +------_=_NextPart_001_01C5993C.1E1CB100 +Content-Type: text/plain; + charset="us-ascii" +Content-Transfer-Encoding: quoted-printable + +I just realised this mail didn't go through. Probably because it was too +large for -hackers. So: repost to -patches. Sorry about that. If it's a +duplicate, even more sorry, but I couldn't find it in the archives. + +(This may explain that nobody answered me :P) + +//Magnus +=20 + +> -----Original Message----- +> From: Magnus Hagander=20 +> Sent: Sunday, July 31, 2005 2:09 PM +> To: PostgreSQL-development +> Cc: pgsql-hackers-win32@postgresql.org +> Subject: Win32 unicode vs ICU +>=20 +> Hi! +>=20 +> I've been working with Palles ICU patch to make it work on=20 +> win32, and I believe I have it done. While doing it I noticed=20 +> that ICU basically converts to UTF16 and back - I previously=20 +> thought it worked on UTF8 strings. Based on this I also tried=20 +> out an implementation for the win32-unicode problem that does=20 +> *not* require ICU. It uses the win32 native functions to map=20 +> to utf16 and back, and then to process the text there. And I=20 +> got through with much less code than the ICU version, while=20 +> doing the same thing. +>=20 +> I am unsure of how to proceed. As I see it there are three paths: +> 1) Use native win32 functionality only on win32 +> 2) Use ICU functionality only on win32 +> 3) Allow both ICU and native functionality, compile time=20 +> switch --with-icu (same as unix with the ICU patch) +>=20 +>=20 +> The main downsides of ICU vs the native ones are: +> * ICU does not accept win32 locale names. When doing=20 +> setlocale("sv_se"), for example, win32 will return this in=20 +> later calls as "Swedish_Sweden.1252". To get around this in=20 +> the ICU patch, I had to implement a lookup map that converts=20 +> it back to sv_se for ICU. +>=20 +> * ICU is yet another build and runtime dependency, and a=20 +> large one (comes in at 11Mb for the DLL files alone in the=20 +> win32 download) +>=20 +>=20 +> I guess that the main upside of it is that we'd get=20 +> constistent behaviour - in case there are issues with either=20 +> ICU or win32 native they'd otherwise differ. And only one new=20 +> codepath. But we already live with the platform-inconsistency today... +>=20 +> Another upside is that it handles more encodings in ICU - my=20 +> native implementation does *only* UTF8 and relies on existing=20 +> functionality to deal with other encodings. It could of=20 +> course be extended if necessary, but from what I can tell=20 +> UTF8 is the big one. +>=20 +>=20 +>=20 +> I have attached both patches. For the native version, only=20 +> win32_utf8.patch is required. For the ICU version,=20 +> icu_win32.patch is needed and also the files=20 +> localemap.c,localemap.pl, iso639 and iso3166 needs to go in=20 +> src/backend/port/win32. (the localemap needs to be updated to=20 +> do a better-than-linear search, but I wanted to include an example) +>=20 +>=20 +> Thoughts on the options? +>=20 +>=20 +> And anohter question - my native patch touches the same=20 +> functions as the ICU patch. Can somebody who knows the=20 +> internals confirm or deny that these are all the required=20 +> locations, or do we need to modify more? +>=20 +> (I have run simple tests in swedish locale and both behave=20 +> the same and correct, but I'm unsure of exactly how much=20 +> would be affected) +>=20 +> Finally, the win32 patch also changes the normal path to use=20 +> strncoll(). The comment above the function states that we'd=20 +> like to use strncoll but it's not available. Well, on win32=20 +> it is, so it should provide a speedup on win32. It is=20 +> currently not included in the ICU patch, but should probably=20 +> be included whichever path we'd chose. +>=20 +>=20 +> //Magnus +>=20 + +------_=_NextPart_001_01C5993C.1E1CB100 +Content-Type: application/octet-stream; + name="win32_utf8.patch" +Content-Transfer-Encoding: base64 +Content-Description: win32_utf8.patch +Content-Disposition: attachment; + filename="win32_utf8.patch" + +SW5kZXg6IHNyYy9iYWNrZW5kL3V0aWxzL2FkdC9vcmFjbGVfY29tcGF0LmMN +Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 +PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvcHJvamVjdHMv +Y3Zzcm9vdC9wZ3NxbC9zcmMvYmFja2VuZC91dGlscy9hZHQvb3JhY2xlX2Nv +bXBhdC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS42MA0KZGlmZiAtYyAt +cjEuNjAgb3JhY2xlX2NvbXBhdC5jDQoqKiogc3JjL2JhY2tlbmQvdXRpbHMv +YWR0L29yYWNsZV9jb21wYXQuYwk3IE1heSAyMDA1IDE1OjE4OjE3IC0wMDAw +CTEuNjANCi0tLSBzcmMvYmFja2VuZC91dGlscy9hZHQvb3JhY2xlX2NvbXBh +dC5jCTMxIEp1bCAyMDA1IDExOjExOjI4IC0wMDAwDQoqKioqKioqKioqKioq +KioNCioqKiAxNDksMTU0ICoqKioNCi0tLSAxNDksMjA5IC0tLS0NCiAgI2Vu +ZGlmICAgLyogVVNFX1dJREVfVVBQRVJfTE9XRVIgKi8NCiAgDQogIA0KKyAj +aWZkZWYgV0lOMzINCisgLyogV2luMzIgVVRGOC9VVEYxNiBjb252ZXJzaW9u +IGhlbHBlcnMgKi8NCisgc3RhdGljIHdjaGFyX3QgKndpbjMyX3V0Zjh0ZXh0 +dG91dGYxNihjb25zdCB0ZXh0ICp0eHQpDQorIHsNCisgCWludAkJCW5ieXRl +cyA9IFZBUlNJWkUodHh0KSAtIFZBUkhEUlNaOwkNCisgCXdjaGFyX3QgICAg +KnJlc3VsdDsNCisgCWludCAgICAgICAgIHI7DQorIA0KKyAJaWYgKG5ieXRl +cyA8IDAgfHwNCisgCQkJbmJ5dGVzID4gKGludCkgKElOVF9NQVggLyBzaXpl +b2Yod2NoYXJfdCkpIC0xKQ0KKyAJCWVyZXBvcnQoRVJST1IsDQorIAkJCQko +ZXJyY29kZShFUlJDT0RFX09VVF9PRl9NRU1PUlkpLA0KKyAJCQkJIGVycm1z +Zygib3V0IG9mIG1lbW9yeSIpKSk7DQorIA0KKyAJLyogT3V0cHV0IHdvcmtz +cGFjZSBjYW5ub3QgaGF2ZSBtb3JlIGNvZGVzIHRoYW4gaW5wdXQgYnl0ZXMg +Ki8NCisgCXJlc3VsdCA9ICh3Y2hhcl90ICopIHBhbGxvYygobmJ5dGVzICsg +MSkgKiBzaXplb2Yod2NoYXJfdCkpOw0KKyANCisgCS8qIERvIHRoZSBjb252 +ZXJzaW9uICovDQorIAlyID0gTXVsdGlCeXRlVG9XaWRlQ2hhcihDUF9VVEY4 +LCAwLCBWQVJEQVRBKHR4dCksICBuYnl0ZXMsDQorIAkJCQlyZXN1bHQsIG5i +eXRlcyAqIHNpemVvZih3Y2hhcl90KSk7DQorIAlpZiAoIXIpDQorIAkJZXJl +cG9ydChFUlJPUiwNCisgCQkJCShlcnJjb2RlKEVSUkNPREVfQ0hBUkFDVEVS +X05PVF9JTl9SRVBFUlRPSVJFKSwNCisgCQkJCSBlcnJtc2coImludmFsaWQg +bXVsdGlieXRlIGNoYXJhY3RlciBmb3IgbG9jYWxlIiksDQorIAkJCQkgZXJy +aGludCgiVGhlIHNlcnZlcidzIExDX0NUWVBFIGxvY2FsZSBpcyBwcm9iYWJs +eSBpbmNvbXBhdGlibGUgd2l0aCB0aGUgZGF0YWJhc2UgZW5jb2RpbmcuIikp +KTsNCisgDQorIAlyZXN1bHRbcl0gPSAwOwkNCisgCXJldHVybiByZXN1bHQ7 +DQorIH0NCisgDQorIHN0YXRpYyB0ZXh0ICp3aW4zMl91dGYxNnRvdXRmOHRl +eHQoY29uc3Qgd2NoYXJfdCAqdHh0KQ0KKyB7DQorIAl0ZXh0CQkqcmVzdWx0 +Ow0KKyAJaW50CQkJIG5ieXRlczsNCisgCWludAkJCSByOw0KKyAJDQorIAlu +Ynl0ZXMgPSBXaWRlQ2hhclRvTXVsdGlCeXRlKENQX1VURjgsIDAsIHR4dCwg +LTEsIE5VTEwsIDAsIE5VTEwsIE5VTEwpOw0KKyAJaWYgKG5ieXRlcyA9PSAw +KQ0KKyAJCWVyZXBvcnQoRVJST1IsDQorIAkJCQkoZXJyY29kZShFUlJDT0RF +X0NIQVJBQ1RFUl9OT1RfSU5fUkVQRVJUT0lSRSksDQorIAkJCQkgZXJybXNn +KCJpbnZhbGlkIHV0ZjE2IGNoYXJhY3RlciBmb3IgbG9jYWxlOiAlbHUiLEdl +dExhc3RFcnJvcigpKSkpOw0KKyANCisgCXJlc3VsdCA9IHBhbGxvYyhuYnl0 +ZXMrVkFSSERSU1opOw0KKyANCisgCXIgPSBXaWRlQ2hhclRvTXVsdGlCeXRl +KENQX1VURjgsIDAsIHR4dCwgLTEsIFZBUkRBVEEocmVzdWx0KSwgbmJ5dGVz +LCBOVUxMLCBOVUxMKTsNCisgCWlmIChyID09IDApDQorIAkJZXJlcG9ydChF +UlJPUiwNCisgCQkJCShlcnJjb2RlKEVSUkNPREVfQ0hBUkFDVEVSX05PVF9J +Tl9SRVBFUlRPSVJFKSwNCisgCQkJCSBlcnJtc2coImludmFsaWQgdXRmMTYg +Y2hhcmFjdGVyIGZvciBsb2NhbGU6ICVsdSIsR2V0TGFzdEVycm9yKCkpKSk7 +DQorIA0KKyAJVkFSQVRUX1NJWkVQKHJlc3VsdCkgPSBuYnl0ZXMgKyBWQVJI +RFJTWiAtIDE7IC8qIC0xID0gaWdub3JlIG51bGwgKi8NCisgCXJldHVybiBy +ZXN1bHQ7DQorIH0NCisgI2VuZGlmIC8qIFdJTjMyICovDQorIA0KICAvKioq +KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq +KioqKioqKioqKioqKioqKioqKioNCiAgICoNCiAgICogbG93ZXINCioqKioq +KioqKioqKioqKg0KKioqIDE3OSwxODQgKioqKg0KLS0tIDIzNCwyNTEgLS0t +LQ0KICAJCXdjaGFyX3QgICAgKndvcmtzcGFjZTsNCiAgCQlpbnQJCQlpOw0K +ICANCisgI2lmZGVmIFdJTjMyDQorIAkJLyogV2luMzIgZG9lcyBub3QgaGF2 +ZSBVVEYtOCwgc28gd2UgbmVlZCB0byBtYXAgdG8gVVRGLTE2ICovDQorIAkJ +aWYgKEdldERhdGFiYXNlRW5jb2RpbmcoKSA9PSBQR19VVEY4KQ0KKyAJCXsN +CisgCQkJd29ya3NwYWNlID0gd2luMzJfdXRmOHRleHR0b3V0ZjE2KHN0cmlu +Zyk7DQorIAkJCV93Y3Nsd3Iod29ya3NwYWNlKTsNCisgCQkJcmVzdWx0ID0g +d2luMzJfdXRmMTZ0b3V0Zjh0ZXh0KHdvcmtzcGFjZSk7DQorIAkJCXBmcmVl +KHdvcmtzcGFjZSk7DQorIAkJCVBHX1JFVFVSTl9URVhUX1AocmVzdWx0KTsN +CisgCQl9DQorICNlbmRpZg0KKyAJCQ0KICAJCXdvcmtzcGFjZSA9IHRleHR0 +b3djcyhzdHJpbmcpOw0KICANCiAgCQlmb3IgKGkgPSAwOyB3b3Jrc3BhY2Vb +aV0gIT0gMDsgaSsrKQ0KKioqKioqKioqKioqKioqDQoqKiogMjQ1LDI1MCAq +KioqDQotLS0gMzEyLDMyOSAtLS0tDQogIAkJd2NoYXJfdCAgICAqd29ya3Nw +YWNlOw0KICAJCWludAkJCWk7DQogIA0KKyAjaWZkZWYgV0lOMzINCisgCQkv +KiBXaW4zMiBkb2VzIG5vdCBoYXZlIFVURi04LCBzbyB3ZSBuZWVkIHRvIG1h +cCB0byBVVEYtMTYgKi8NCisgCQlpZiAoR2V0RGF0YWJhc2VFbmNvZGluZygp +ID09IFBHX1VURjgpDQorIAkJew0KKyAJCQl3b3Jrc3BhY2UgPSB3aW4zMl91 +dGY4dGV4dHRvdXRmMTYoc3RyaW5nKTsNCisgCQkJX3djc3Vwcih3b3Jrc3Bh +Y2UpOw0KKyAJCQlyZXN1bHQgPSB3aW4zMl91dGYxNnRvdXRmOHRleHQod29y +a3NwYWNlKTsNCisgCQkJcGZyZWUod29ya3NwYWNlKTsNCisgCQkJUEdfUkVU +VVJOX1RFWFRfUChyZXN1bHQpOw0KKyAJCX0NCisgI2VuZGlmDQorIA0KICAJ +CXdvcmtzcGFjZSA9IHRleHR0b3djcyhzdHJpbmcpOw0KICANCiAgCQlmb3Ig +KGkgPSAwOyB3b3Jrc3BhY2VbaV0gIT0gMDsgaSsrKQ0KKioqKioqKioqKioq +KioqDQoqKiogMzE1LDMyMCAqKioqDQotLS0gMzk0LDQwNSAtLS0tDQogIAkJ +aW50CQkJd2FzYWxudW0gPSAwOw0KICAJCWludAkJCWk7DQogIA0KKyAjaWZk +ZWYgV0lOMzINCisgCQkvKiBXaW4zMiBkb2VzIG5vdCBoYXZlIFVURi04LCBz +byB3ZSBuZWVkIHRvIG1hcCB0byBVVEYtMTYgKi8NCisgCQlpZiAoR2V0RGF0 +YWJhc2VFbmNvZGluZygpID09IFBHX1VURjgpDQorIAkJCXdvcmtzcGFjZSA9 +IHdpbjMyX3V0Zjh0ZXh0dG91dGYxNihzdHJpbmcpOw0KKyAJCWVsc2UNCisg +I2VuZGlmDQogIAkJd29ya3NwYWNlID0gdGV4dHRvd2NzKHN0cmluZyk7DQog +IA0KICAJCWZvciAoaSA9IDA7IHdvcmtzcGFjZVtpXSAhPSAwOyBpKyspDQoq +KioqKioqKioqKioqKioNCioqKiAzMjYsMzMxICoqKioNCi0tLSA0MTEsNDIy +IC0tLS0NCiAgCQkJd2FzYWxudW0gPSBpc3dhbG51bSh3b3Jrc3BhY2VbaV0p +Ow0KICAJCX0NCiAgDQorICNpZmRlZiBXSU4zMg0KKyAJCS8qIE1hcCBiYWNr +IHRvIFVURi04ICovDQorIAkJaWYgKEdldERhdGFiYXNlRW5jb2RpbmcoKSA9 +PSBQR19VVEY4KQ0KKyAJCQlyZXN1bHQgPSB3aW4zMl91dGYxNnRvdXRmOHRl +eHQod29ya3NwYWNlKTsNCisgCQllbHNlDQorICNlbmRpZg0KICAJCXJlc3Vs +dCA9IHdjc3RvdGV4dCh3b3Jrc3BhY2UsIGkpOw0KICANCiAgCQlwZnJlZSh3 +b3Jrc3BhY2UpOw0KSW5kZXg6IHNyYy9iYWNrZW5kL3V0aWxzL2FkdC92YXJs +ZW5hLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 +PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvcHJv +amVjdHMvY3Zzcm9vdC9wZ3NxbC9zcmMvYmFja2VuZC91dGlscy9hZHQvdmFy +bGVuYS5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMzANCmRpZmYgLWMg +LXIxLjEzMCB2YXJsZW5hLmMNCioqKiBzcmMvYmFja2VuZC91dGlscy9hZHQv +dmFybGVuYS5jCTI5IEp1bCAyMDA1IDAzOjE3OjU1IC0wMDAwCTEuMTMwDQot +LS0gc3JjL2JhY2tlbmQvdXRpbHMvYWR0L3ZhcmxlbmEuYwkzMSBKdWwgMjAw +NSAxMToxNTo0OSAtMDAwMA0KKioqKioqKioqKioqKioqDQoqKiogODQ4LDg1 +MyAqKioqDQotLS0gODQ4LDkwMSAtLS0tDQogIAkJY2hhcgkJYTJidWZbU1RB +Q0tCVUZMRU5dOw0KICAJCWNoYXIJICAgKmExcCwNCiAgCQkJCSAgICphMnA7 +DQorICNpZmRlZiBXSU4zMg0KKyAJCS8qIFdpbjMyIGRvZXMgbm90IGhhdmUg +VVRGLTgsIHNvIHdlIG5lZWQgdG8gbWFwIHRvIFVURi0xNiAqLw0KKyAJCWlm +IChHZXREYXRhYmFzZUVuY29kaW5nKCkgPT0gUEdfVVRGOCkNCisgCQl7DQor +IAkJCWludCBhMWxlbiA9IFNUQUNLQlVGTEVOOw0KKyAJCQlpbnQgYTJsZW4g +PSBTVEFDS0JVRkxFTjsNCisgDQorIAkJCWlmIChsZW4xID49IFNUQUNLQlVG +TEVOLzIpDQorIAkJCXsNCisgCQkJCWExbGVuID0gbGVuMSAqIDIgKyAyOw0K +KyAJCQkJYTFwID0gcGFsbG9jKGExbGVuKTsNCisgCQkJfQ0KKyAJCQllbHNl +DQorIAkJCQlhMXAgPSBhMWJ1ZjsNCisgCQkJDQorIAkJCWlmIChsZW4yID49 +IFNUQUNLQlVGTEVOLzIpDQorIAkJCXsNCisgCQkJCWEybGVuID0gbGVuMiAq +IDIgKyAyOw0KKyAJCQkJYTJwID0gcGFsbG9jKGEybGVuKTsNCisgCQkJfQ0K +KyAJCQllbHNlDQorIAkJCQlhMnAgPSBhMmJ1ZjsNCisgDQorIAkJCWlmICgh +TXVsdGlCeXRlVG9XaWRlQ2hhcihDUF9VVEY4LCAwLCBhcmcxLCAtMSwgKExQ +V1NUUilhMXAsIGExbGVuLzIpKQ0KKyAJCQkJZXJlcG9ydChFUlJPUiwNCisg +CQkJCQkJKGVycm1zZygiZmFpbGVkIHRvIGNvbnZlcnQgc3RyaW5nIHRvIFVU +RjE2OiAlbHUiLA0KKyAJCQkJCQkJR2V0TGFzdEVycm9yKCkpKSk7DQorIAkJ +CWlmICghTXVsdGlCeXRlVG9XaWRlQ2hhcihDUF9VVEY4LCAwLCBhcmcyLCAt +MSwgKExQV1NUUilhMnAsIGEybGVuLzIpKQ0KKyAJCQkJZXJlcG9ydChFUlJP +UiwNCisgCQkJCQkJKGVycm1zZygiZmFpbGVkIHRvIGNvbnZlcnQgc3RyaW5n +IHRvIFVURjE2OiAlbHUiLA0KKyAJCQkJCQkJR2V0TGFzdEVycm9yKCkpKSk7 +DQorIAkJCQ0KKyAJCQllcnJubz0wOw0KKyAJCQlyZXN1bHQgPSB3Y3Njb2xs +KChMUFdTVFIpYTFwLCAoTFBXU1RSKWEycCk7DQorIAkJCWlmIChyZXN1bHQg +PT0gMjE0NzQ4MzY0NykgLyogX05MU0NNUEVSUk9SOyBtaXNzaW5nIGZyb20g +bWluZ3cgaGVhZGVycyAqLw0KKyAJCQkJZXJlcG9ydChFUlJPUiwNCisgCQkJ +CQkJKGVycm1zZygiZmFpbGVkIHRvIGNvbXBhcmUgdW5pY29kZSBzdHJpbmdz +OiAlaSIsIGVycm5vKSkpOw0KKyAJCQlpZiAoYTFsZW4gIT0gU1RBQ0tCVUZM +RU4pDQorIAkJCQlwZnJlZShhMXApOw0KKyAJCQlpZiAoYTJsZW4gIT0gU1RB +Q0tCVUZMRU4pDQorIAkJCQlwZnJlZShhMnApOw0KKyAJCQkNCisgCQkJcmV0 +dXJuIHJlc3VsdDsNCisgCQl9DQorIA0KKyAJCS8qIFdpbjMyIGhhcyBzdHJu +Y29sbCgpLCBzbyB1c2UgaXQgdGhlcmUgdG8gYXZvaWQgY29weWluZyAqLw0K +KyAJCXJldHVybiBfc3RybmNvbGwoYXJnMSwgYXJnMiwgKGxlbjE+bGVuMik/ +bGVuMjpsZW4xICk7DQorICNlbmRpZg0KICANCiAgCQlpZiAobGVuMSA+PSBT +VEFDS0JVRkxFTikNCiAgCQkJYTFwID0gKGNoYXIgKikgcGFsbG9jKGxlbjEg +KyAxKTsNCg== + +------_=_NextPart_001_01C5993C.1E1CB100 +Content-Type: application/octet-stream; + name="icu_win32.patch" +Content-Transfer-Encoding: base64 +Content-Description: icu_win32.patch +Content-Disposition: attachment; + filename="icu_win32.patch" + +SW5kZXg6IGNvbmZpZ3VyZS5pbg0KPT09PT09PT09PT09PT09PT09PT09PT09 +PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K +UkNTIGZpbGU6IC9wcm9qZWN0cy9jdnNyb290L3Bnc3FsL2NvbmZpZ3VyZS5p +bix2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNDE3DQpkaWZmIC1jIC1yMS40 +MTcgY29uZmlndXJlLmluDQoqKiogY29uZmlndXJlLmluCTYgSnVsIDIwMDUg +MjE6MDQ6MTMgLTAwMDAJMS40MTcNCi0tLSBjb25maWd1cmUuaW4JMjggSnVs +IDIwMDUgMTc6MDE6NDcgLTAwMDANCioqKioqKioqKioqKioqKg0KKioqIDQ2 +Nyw0NzIgKioqKg0KLS0tIDQ2Nyw0ODAgLS0tLQ0KICBBQ19NU0dfUkVTVUxU +KFskd2l0aF9vcGVuc3NsXSkNCiAgQUNfU1VCU1Qod2l0aF9vcGVuc3NsKQ0K +ICANCisgIw0KKyAjIElDVQ0KKyAjDQorIEFDX01TR19DSEVDS0lORyhbd2hl +dGhlciB0byBidWlsZCB3aXRoIElDVSBzdXBwb3J0XSkNCisgUEdBQ19BUkdf +Qk9PTCh3aXRoLCBpY3UsIG5vLCBbICAtLXdpdGgtaWN1ICAgICAgICAgICAg +ICBidWlsZCB3aXRoIElDVSBzdXBwb3J0XSwNCisgICAgICAgICAgICAgICBb +QUNfREVGSU5FKFtVU0VfSUNVXSwgMSwgW0RlZmluZSB0byBidWlsZCB3aXRo +IElDVSBzdXBwb3J0LiAoLS13aXRoLWljdSldKV0pDQorIEFDX01TR19SRVNV +TFQoWyR3aXRoX2ljdV0pDQorIEFDX1NVQlNUKHdpdGhfaWN1KQ0KICANCiAg +Iw0KICAjIFJlYWRsaW5lDQoqKioqKioqKioqKioqKioNCioqKiA2NzQsNjc5 +ICoqKioNCi0tLSA2ODIsNjk4IC0tLS0NCiAgICBmaQ0KICBmaQ0KICANCisg +aWYgdGVzdCAiJHdpdGhfaWN1IiA9IHllcyA7IHRoZW4NCisgICBpZiB0ZXN0 +ICIkUE9SVE5BTUUiICE9ICJ3aW4zMiI7IHRoZW4NCisgICAgIEFDX0NIRUNL +X0xJQihpY3VpMThuLCB1Y29sX29wZW5fM18yLCBbXSwgW0FDX01TR19FUlJP +UihbbGlicmFyeSAnaWN1aTE4bicgaXMgcmVxdWlyZWQgZm9yIElDVV0pXSkN +CisgICAgIEFDX0NIRUNLX0xJQihpY3V1YywgIHVfdG9sb3dlcl8zXzIsIFtd +LCBbQUNfTVNHX0VSUk9SKFtsaWJyYXJ5ICdpY3V1YycgaXMgcmVxdWlyZWQg +Zm9yIElDVV0pXSkNCisgICAgIEFDX0NIRUNLX0xJQihpY3VkYXRhLCBpY3Vk +dDMyX2RhdCwgW10sIFtBQ19NU0dfRVJST1IoW2xpYnJhcnkgJ2ljdWRhdGEn +IGlzIHJlcXVpcmVkIGZvciBJQ1VdKV0pDQorICAgZWxzZQ0KKyAgICAgQUNf +Q0hFQ0tfTElCKGljdWluLCB1Y29sX29wZW5fM18yLCBbXSwgW0FDX01TR19F +UlJPUihbbGlicmFyeSAnaWN1aW4nIGlzIHJlcXVpcmVkIGZvciBJQ1VdKV0p +DQorICAgICBBQ19DSEVDS19MSUIoaWN1dWMsICB1X3RvbG93ZXJfM18yLCBb +XSwgW0FDX01TR19FUlJPUihbbGlicmFyeSAnaWN1dWMnIGlzIHJlcXVpcmVk +IGZvciBJQ1VdKV0pDQorICAgZmkNCisgZmkNCisgICANCiAgaWYgdGVzdCAi +JHdpdGhfcGFtIiA9IHllcyA7IHRoZW4NCiAgICBBQ19DSEVDS19MSUIocGFt +LCAgICBwYW1fc3RhcnQsIFtdLCBbQUNfTVNHX0VSUk9SKFtsaWJyYXJ5ICdw +YW0nIGlzIHJlcXVpcmVkIGZvciBQQU1dKV0pDQogIGZpDQoqKioqKioqKioq +KioqKioNCioqKiA3NDgsNzUzICoqKioNCi0tLSA3NjcsNzc2IC0tLS0NCiAg +ICBBQ19DSEVDS19IRUFERVIob3BlbnNzbC9lcnIuaCwgW10sIFtBQ19NU0df +RVJST1IoW2hlYWRlciBmaWxlIDxvcGVuc3NsL2Vyci5oPiBpcyByZXF1aXJl +ZCBmb3IgT3BlblNTTF0pXSkNCiAgZmkNCiAgDQorIGlmIHRlc3QgIiR3aXRo +X2ljdSIgPSB5ZXMgOyB0aGVuDQorICAgQUNfQ0hFQ0tfSEVBREVSKHVuaWNv +ZGUvdXR5cGVzLmgsIFtdLCBbQUNfTVNHX0VSUk9SKFtoZWFkZXIgZmlsZSA8 +dW5pY29kZS91dHlwZXMuaD4gaXMgcmVxdWlyZWQgZm9yIElDVV0pXSkNCisg +ZmkNCisgIA0KICBpZiB0ZXN0ICIkd2l0aF9wYW0iID0geWVzIDsgdGhlbg0K +ICAgIEFDX0NIRUNLX0hFQURFUlMoc2VjdXJpdHkvcGFtX2FwcGwuaCwgW10s +DQogICAgICAgICAgICAgICAgICAgICBbQUNfQ0hFQ0tfSEVBREVSUyhwYW0v +cGFtX2FwcGwuaCwgW10sDQpJbmRleDogc3JjL2JhY2tlbmQvcG9ydC93aW4z +Mi9NYWtlZmlsZQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 +PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6 +IC9wcm9qZWN0cy9jdnNyb290L3Bnc3FsL3NyYy9iYWNrZW5kL3BvcnQvd2lu +MzIvTWFrZWZpbGUsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjYNCmRpZmYg +LWMgLXIxLjYgTWFrZWZpbGUNCioqKiBzcmMvYmFja2VuZC9wb3J0L3dpbjMy +L01ha2VmaWxlCTI5IEF1ZyAyMDA0IDAwOjM4OjAzIC0wMDAwCTEuNg0KLS0t +IHNyYy9iYWNrZW5kL3BvcnQvd2luMzIvTWFrZWZpbGUJMzAgSnVsIDIwMDUg +MTc6NTI6NDcgLTAwMDANCioqKioqKioqKioqKioqKg0KKioqIDEyLDI5ICoq +KioNCiAgdG9wX2J1aWxkZGlyID0gLi4vLi4vLi4vLi4NCiAgaW5jbHVkZSAk +KHRvcF9idWlsZGRpcikvc3JjL01ha2VmaWxlLmdsb2JhbA0KICANCiEgT0JK +UyA9IHNlbWEubyBzaG1lbS5vIHRpbWVyLm8gc29ja2V0Lm8gc2lnbmFsLm8g +c2VjdXJpdHkubyBlcnJvci5vDQogIA0KICBhbGw6IFNVQlNZUy5vDQogIA0K +ICBTVUJTWVMubzogJChPQkpTKQ0KICAJJChMRCkgJChMRFJFTCkgJChMRE9V +VCkgU1VCU1lTLm8gJChPQkpTKQ0KICANCiAgZGVwZW5kIGRlcDoNCiAgCSQo +Q0MpIC1NTSAkKENGTEFHUykgKi5jID5kZXBlbmQNCiAgDQogIGNsZWFuOiAN +CiEgCXJtIC1mIFNVQlNZUy5vICQoT0JKUykNCiAgDQogIGlmZXEgKGRlcGVu +ZCwkKHdpbGRjYXJkIGRlcGVuZCkpDQogIGluY2x1ZGUgZGVwZW5kDQotLS0g +MTIsMzQgLS0tLQ0KICB0b3BfYnVpbGRkaXIgPSAuLi8uLi8uLi8uLg0KICBp +bmNsdWRlICQodG9wX2J1aWxkZGlyKS9zcmMvTWFrZWZpbGUuZ2xvYmFsDQog +IA0KISBPQkpTID0gc2VtYS5vIHNobWVtLm8gdGltZXIubyBzb2NrZXQubyBz +aWduYWwubyBzZWN1cml0eS5vIGVycm9yLm8gbG9jYWxlbWFwLm8NCiAgDQog +IGFsbDogU1VCU1lTLm8NCiAgDQogIFNVQlNZUy5vOiAkKE9CSlMpDQogIAkk +KExEKSAkKExEUkVMKSAkKExET1VUKSBTVUJTWVMubyAkKE9CSlMpDQogIA0K +KyBsb2NhbGVtYXAubzogbG9jYWxlbWFwLmMgbG9jYWxlbWFwLmgNCisgDQor +IGxvY2FsZW1hcC5oOiBpc282MzkgaXNvMzE2NiBsb2NhbGVtYXAucGwNCisg +CSQoUEVSTCkgbG9jYWxlbWFwLnBsID4gbG9jYWxlbWFwLmgNCisgDQogIGRl +cGVuZCBkZXA6DQogIAkkKENDKSAtTU0gJChDRkxBR1MpICouYyA+ZGVwZW5k +DQogIA0KICBjbGVhbjogDQohIAlybSAtZiBTVUJTWVMubyAkKE9CSlMpIGxv +Y2FsZW1hcC5oDQogIA0KICBpZmVxIChkZXBlbmQsJCh3aWxkY2FyZCBkZXBl +bmQpKQ0KICBpbmNsdWRlIGRlcGVuZA0KSW5kZXg6IHNyYy9iYWNrZW5kL3V0 +aWxzL2FkdC9vcmFjbGVfY29tcGF0LmMNCj09PT09PT09PT09PT09PT09PT09 +PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 +PT0NClJDUyBmaWxlOiAvcHJvamVjdHMvY3Zzcm9vdC9wZ3NxbC9zcmMvYmFj +a2VuZC91dGlscy9hZHQvb3JhY2xlX2NvbXBhdC5jLHYNCnJldHJpZXZpbmcg +cmV2aXNpb24gMS42MA0KZGlmZiAtYyAtcjEuNjAgb3JhY2xlX2NvbXBhdC5j +DQoqKiogc3JjL2JhY2tlbmQvdXRpbHMvYWR0L29yYWNsZV9jb21wYXQuYwk3 +IE1heSAyMDA1IDE1OjE4OjE3IC0wMDAwCTEuNjANCi0tLSBzcmMvYmFja2Vu +ZC91dGlscy9hZHQvb3JhY2xlX2NvbXBhdC5jCTMwIEp1bCAyMDA1IDE0OjU5 +OjI5IC0wMDAwDQoqKioqKioqKioqKioqKioNCioqKiAzMiwzNyAqKioqDQot +LS0gMzIsNDMgLS0tLQ0KICAjaW5jbHVkZSAidXRpbHMvcGdfbG9jYWxlLmgi +DQogICNpbmNsdWRlICJtYi9wZ193Y2hhci5oIg0KICANCisgI2lmZGVmIFVT +RV9JQ1UNCisgI2luY2x1ZGUgPHVuaWNvZGUvdXR5cGVzLmg+ICAgLyogQmFz +aWMgSUNVIGRhdGEgdHlwZXMgKi8NCisgI2luY2x1ZGUgPHVuaWNvZGUvdWNu +di5oPiAgICAgLyogQyAgIENvbnZlcnRlciBBUEkgICAgKi8NCisgI2luY2x1 +ZGUgPHVuaWNvZGUvdXN0cmluZy5oPg0KKyAjZW5kaWYgLyogVVNFX0lDVSAq +Lw0KKyANCiAgDQogIC8qDQogICAqIElmIHRoZSBzeXN0ZW0gcHJvdmlkZXMg +dGhlIG5lZWRlZCBmdW5jdGlvbnMgZm9yIHdpZGUtY2hhcmFjdGVyIG1hbmlw +dWxhdGlvbg0KKioqKioqKioqKioqKioqDQoqKiogNTMsNTggKioqKg0KLS0t +IDU5LDEwNiAtLS0tDQogIAkgICBib29sIGRvbHRyaW0sIGJvb2wgZG9ydHJp +bSk7DQogIA0KICANCisgI2lmZGVmIFVTRV9JQ1UNCisgc3RhdGljIFVDb252 +ZXJ0ZXIgKmNvbnYgPSBOVUxMOw0KKyANCisgc3RhdGljIHRleHQgKg0KKyBV +Q2hhcnRvdGV4dChjb25zdCBVQ2hhciAqc3RyLCBpbnQgbmNvZGVzKQ0KKyB7 +DQorIAl0ZXh0CSAgICpyZXN1bHQ7DQorIAlzaXplX3QJCW5ieXRlcywgcmVz +dWx0c2l6ZTsNCisgDQorIAlVRXJyb3JDb2RlIHN0YXR1cyA9IFVfWkVST19F +UlJPUjsNCisgDQorIAkvKiBPdmVyZmxvdyBwYXJhbm9pYSAqLw0KKyAJaWYg +KG5jb2RlcyA8IDAgfHwNCisgCQluY29kZXMgPiAoaW50KSAoKElOVF9NQVgg +LSBWQVJIRFJTWikgLyBzaXplb2YoVUNoYXIpKSAtIDEpDQorIAkJZXJlcG9y +dChFUlJPUiwNCisgCQkJCShlcnJjb2RlKEVSUkNPREVfT1VUX09GX01FTU9S +WSksDQorIAkJCQkgZXJybXNnKCJvdXQgb2YgbWVtb3J5IikpKTsNCisgDQor +IAkvKiBNYWtlIHdvcmtzcGFjZSBjZXJ0YWlubHkgbGFyZ2UgZW5vdWdoIGZv +ciByZXN1bHQgKi8NCisgCXJlc3VsdHNpemUgPSBVQ05WX0dFVF9NQVhfQllU +RVNfRk9SX1NUUklORyhuY29kZXMsIHVjbnZfZ2V0TWF4Q2hhclNpemUoY29u +dikpOw0KKyAJcmVzdWx0ID0gKHRleHQgKikgcGFsbG9jKHJlc3VsdHNpemUg +KyBWQVJIRFJTWik7DQorIA0KKyAJbmJ5dGVzID0gdWNudl9mcm9tVUNoYXJz +KGNvbnYsIFZBUkRBVEEocmVzdWx0KSwgcmVzdWx0c2l6ZSwNCisgCQkJCQkJ +CSBzdHIsIG5jb2RlcywgJnN0YXR1cyk7DQorIA0KKyAJaWYgKFVfRkFJTFVS +RShzdGF0dXMpKQ0KKyAJew0KKyAJCS8qIEludmFsaWQgbXVsdGlieXRlIGNo +YXJhY3RlciBlbmNvdW50ZXJlZCAuLi4gc2hvdWxkbid0IGhhcHBlbiAqLw0K +KyAJCWVyZXBvcnQoRVJST1IsDQorIAkJCQkoZXJyY29kZShFUlJDT0RFX0NI +QVJBQ1RFUl9OT1RfSU5fUkVQRVJUT0lSRSksDQorIAkJCQkgZXJybXNnKCJp +bnZhbGlkIG11bHRpYnl0ZSBjaGFyYWN0ZXIgZm9yIGxvY2FsZSIpKSk7DQor +IAl9DQorIA0KKyAJQXNzZXJ0KG5ieXRlcyA8PSAoc2l6ZV90KSAobmNvZGVz +ICogc2l6ZW9mKFVDaGFyKSkpOw0KKyANCisgCVZBUkFUVF9TSVpFUChyZXN1 +bHQpID0gbmJ5dGVzICsgVkFSSERSU1o7DQorIA0KKyAJcmV0dXJuIHJlc3Vs +dDsNCisgfQ0KKyANCisgDQorICNlbHNlDQogICNpZmRlZiBVU0VfV0lERV9V +UFBFUl9MT1dFUg0KICANCiAgLyoNCioqKioqKioqKioqKioqKg0KKioqIDE0 +NywxNTIgKioqKg0KLS0tIDE5NSwyMDEgLS0tLQ0KICAJcmV0dXJuIHJlc3Vs +dDsNCiAgfQ0KICAjZW5kaWYgICAvKiBVU0VfV0lERV9VUFBFUl9MT1dFUiAq +Lw0KKyAjZW5kaWYgICAvKiBVU0VfSUNVICovDQogIA0KICANCiAgLyoqKioq +KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq +KioqKioqKioqKioqKioqKioqDQoqKioqKioqKioqKioqKioNCioqKiAxNjYs +MTcxICoqKioNCi0tLSAyMTUsMjg2IC0tLS0NCiAgRGF0dW0NCiAgbG93ZXIo +UEdfRlVOQ1RJT05fQVJHUykNCiAgew0KKyAjaWZkZWYgVVNFX0lDVQ0KKyAj +ZGVmaW5lIFNUQUNLQlVGTEVOCQkxMDI0IC8gc2l6ZW9mKFVDaGFyKQ0KKyAJ +LyogdXNlIElDVSBvbmx5IHdoZW4gbWF4IGVuY29kaW5nIGxlbmd0aCA+IG9u +ZSAqLw0KKyAJaWYgKHBnX2RhdGFiYXNlX2VuY29kaW5nX21heF9sZW5ndGgo +KSA+IDEpDQorIAl7DQorIAkJdGV4dAkgICAqc3RyaW5nID0gUEdfR0VUQVJH +X1RFWFRfUCgwKTsNCisgCQl0ZXh0CSAgICpyZXN1bHQ7DQorIAkJVUNoYXIg +ICAgICAgc291cmNlYnVmW1NUQUNLQlVGTEVOXSwgZGVzdGJ1ZltTVEFDS0JV +RkxFTl07DQorIAkJVUNoYXIgICAgICAqc291cmNlLCAqZGVzdDsNCisgCQlp +bnQJCQlidWZsZW4sDQorIAkJCQkJYXJnbGVuID0gVkFSU0laRShzdHJpbmcp +IC0gVkFSSERSU1o7DQorIAkJVUVycm9yQ29kZSAgc3RhdHVzID0gVV9aRVJP +X0VSUk9SOw0KKyANCisgCQlpZiAoY29udiA9PSBOVUxMKQ0KKyAJCXsNCisg +CQkJY29udiA9IHVjbnZfb3BlbihOVUxMLCAmc3RhdHVzKTsNCisgCQkJaWYg +KFVfRkFJTFVSRShzdGF0dXMpKQ0KKyAJCQl7DQorIAkJCQllcmVwb3J0KEVS +Uk9SLA0KKyAJCQkJCQkoZXJyY29kZShzdGF0dXMpLA0KKyAJCQkJCQkgZXJy +bXNnKCJJQ1UgZXJyb3I6IG9yYWNsZV9jb21wYXQuYywgY291bGQgbm90IGdl +dCBjb252ZXJ0ZXIgZm9yIFwiJXNcIiIsIHVjbnZfZ2V0RGVmYXVsdE5hbWUo +KSkpKTsNCisgCQkJfQ0KKyAJCX0NCisgDQorIAkJaWYgKGFyZ2xlbiA+PSBT +VEFDS0JVRkxFTiAvIHNpemVvZihVQ2hhcikpDQorIAkJew0KKyAJCQlidWZs +ZW4gPSBhcmdsZW4gKiBzaXplb2YoVUNoYXIpICsgMTsNCisgIAkJCXNvdXJj +ZSA9IHBhbGxvYyhidWZsZW4pOw0KKyAJCQlkZXN0ID0gcGFsbG9jKGJ1Zmxl +bik7DQorIAkJfQ0KKyAJCWVsc2UNCisgCQl7DQorIAkJCWJ1ZmxlbiA9IFNU +QUNLQlVGTEVOOw0KKyAJCQlzb3VyY2UgPSBzb3VyY2VidWY7DQorIAkJCWRl +c3QgPSBkZXN0YnVmOw0KKyAJCX0NCisgCQkvLyBjb252ZXJ0IHRvIFVURi0x +Ng0KKyAJCXVjbnZfdG9VQ2hhcnMoY29udiwgc291cmNlLCBidWZsZW4sIFZB +UkRBVEEoc3RyaW5nKSwgYXJnbGVuLCAmc3RhdHVzKTsNCisgCQlpZiAoVV9G +QUlMVVJFKHN0YXR1cykpDQorIAkJew0KKyAJCQllcmVwb3J0KEVSUk9SLA0K +KyAJCQkJCQkoZXJyY29kZShzdGF0dXMpLA0KKyAJCQkJCQkgZXJybXNnKCJJ +Q1UgZXJyb3I6IENvdWxkIG5vdCBjb252ZXJ0IHN0cmluZyIpKSk7DQorIAkJ +fQ0KKyAJCQ0KKyAJCS8vIHJ1biBkZXNpcmVkIGZ1bmN0aW9uDQorIAkJYnVm +bGVuID0gdV9zdHJUb0xvd2VyKGRlc3QsIGJ1Zmxlbiwgc291cmNlLCAtMSwg +TlVMTCwgJnN0YXR1cyk7DQorIAkJaWYgKFVfRkFJTFVSRShzdGF0dXMpKQ0K +KyAJCXsNCisgCQkJZXJlcG9ydChFUlJPUiwNCisgCQkJCQkJKGVycmNvZGUo +c3RhdHVzKSwNCisgCQkJCQkJIGVycm1zZygiSUNVIGVycm9yOiBDb3VsZCBu +b3QgbW9kaWZ5IGNhc2UiKSkpOw0KKyAJCX0NCisgDQorIAkJLy8gYW5kIGNv +bnZlcnQgbW9kaWZpZWQgdXRmLTE2IHN0cmluZyBiYWNrIHRvIHRleHQNCisg +CQlyZXN1bHQgPSBVQ2hhcnRvdGV4dChkZXN0LCBidWZsZW4pOw0KKyANCisg +CQlpZiAoYXJnbGVuID49IFNUQUNLQlVGTEVOIC8gc2l6ZW9mKFVDaGFyKSkN +CisgCQl7DQorIAkJCXBmcmVlKHNvdXJjZSk7DQorIAkJCXBmcmVlKGRlc3Qp +Ow0KKyAJCX0NCisgCQlQR19SRVRVUk5fVEVYVF9QKHJlc3VsdCk7DQorIAl9 +DQorIAllbHNlDQorICNlbHNlDQogICNpZmRlZiBVU0VfV0lERV9VUFBFUl9M +T1dFUg0KICAJLyoNCiAgCSAqCVVzZSB3aWRlIGNoYXIgY29kZSBvbmx5IHdo +ZW4gbWF4IGVuY29kaW5nIGxlbmd0aCA+IDEgYW5kIGN0eXBlICE9IEMuDQoq +KioqKioqKioqKioqKioNCioqKiAxOTIsMTk3ICoqKioNCi0tLSAzMDcsMzEz +IC0tLS0NCiAgCX0NCiAgCWVsc2UNCiAgI2VuZGlmICAgLyogVVNFX1dJREVf +VVBQRVJfTE9XRVIgKi8NCisgI2VuZGlmICAgLyogVVNFX0lDVSAqLw0KICAJ +ew0KICAJCXRleHQJICAgKnN0cmluZyA9IFBHX0dFVEFSR19URVhUX1BfQ09Q +WSgwKTsNCiAgCQljaGFyCSAgICpwdHI7DQoqKioqKioqKioqKioqKioNCioq +KiAyMzIsMjM3ICoqKioNCi0tLSAzNDgsNDE4IC0tLS0NCiAgRGF0dW0NCiAg +dXBwZXIoUEdfRlVOQ1RJT05fQVJHUykNCiAgew0KKyAjaWZkZWYgVVNFX0lD +VQ0KKyAJLyogdXNlIElDVSBvbmx5IHdoZW4gbWF4IGVuY29kaW5nIGxlbmd0 +aCA+IG9uZSAqLw0KKyAJaWYgKHBnX2RhdGFiYXNlX2VuY29kaW5nX21heF9s +ZW5ndGgoKSA+IDEpDQorIAl7DQorIAkJdGV4dAkgICAqc3RyaW5nID0gUEdf +R0VUQVJHX1RFWFRfUCgwKTsNCisgCQl0ZXh0CSAgICpyZXN1bHQ7DQorIAkJ +VUNoYXIgICAgICAgc291cmNlYnVmW1NUQUNLQlVGTEVOXSwgZGVzdGJ1ZltT +VEFDS0JVRkxFTl07DQorIAkJVUNoYXIgICAgICAqc291cmNlLCAqZGVzdDsN +CisgCQlpbnQzMl90ICAgICBidWZsZW4sIGFyZ2xlbjsNCisgDQorIAkJVUVy +cm9yQ29kZSAgc3RhdHVzID0gVV9aRVJPX0VSUk9SOw0KKyANCisgCQlpZiAo +Y29udiA9PSBOVUxMKQ0KKyAJCXsNCisgCQkJY29udiA9IHVjbnZfb3BlbihO +VUxMLCAmc3RhdHVzKTsNCisgCQkJaWYgKFVfRkFJTFVSRShzdGF0dXMpKQ0K +KyAJCQl7DQorIAkJCQllcmVwb3J0KEVSUk9SLA0KKyAJCQkJCQkoZXJyY29k +ZShzdGF0dXMpLA0KKyAJCQkJCQkgZXJybXNnKCJJQ1UgZXJyb3I6IENvdWxk +IG5vdCBnZXQgY29udmVydGVyIGZvciBcIiVzXCIiLCB1Y252X2dldERlZmF1 +bHROYW1lKCkpKSk7DQorIAkJCX0NCisgCQl9DQorIAkJYXJnbGVuID0gVkFS +U0laRShzdHJpbmcpIC0gVkFSSERSU1o7DQorIAkJaWYgKGFyZ2xlbiAqIHNp +emVvZihVQ2hhcikgPj0gU1RBQ0tCVUZMRU4pDQorIAkJew0KKyAJCQlidWZs +ZW4gPSBhcmdsZW4gKiBzaXplb2YoVUNoYXIpICsgMTsNCisgIAkJCXNvdXJj +ZSA9IHBhbGxvYyhidWZsZW4pOw0KKyAJCQlkZXN0ID0gcGFsbG9jKGJ1Zmxl +bik7DQorIAkJfQ0KKyAJCWVsc2UNCisgCQl7DQorIAkJCWJ1ZmxlbiA9IFNU +QUNLQlVGTEVOOw0KKyAJCQlzb3VyY2UgPSBzb3VyY2VidWY7DQorIAkJCWRl +c3QgPSBkZXN0YnVmOw0KKyAJCX0NCisgCQkvLyBjb252ZXJ0IHRvIFVURi0x +Ng0KKyAJCXVjbnZfdG9VQ2hhcnMoY29udiwgc291cmNlLCBidWZsZW4sIFZB +UkRBVEEoc3RyaW5nKSwgYXJnbGVuLCAmc3RhdHVzKTsNCisgCQlpZiAoVV9G +QUlMVVJFKHN0YXR1cykpDQorIAkJew0KKyAJCQllcmVwb3J0KEVSUk9SLA0K +KyAJCQkJCQkoZXJyY29kZShzdGF0dXMpLA0KKyAJCQkJCQkgZXJybXNnKCJJ +Q1UgZXJyb3I6IENvdWxkIG5vdCBjb252ZXJ0IHN0cmluZyIpKSk7DQorIAkJ +fQ0KKyANCisgCQkvLyBydW4gZGVzaXJlZCBmdW5jdGlvbg0KKyAJCWJ1Zmxl +biA9IHVfc3RyVG9VcHBlcihkZXN0LCBidWZsZW4sIHNvdXJjZSwgLTEsIE5V +TEwsICZzdGF0dXMpOw0KKyAJCWlmIChVX0ZBSUxVUkUoc3RhdHVzKSkNCisg +CQl7DQorIAkJCWVyZXBvcnQoRVJST1IsDQorIAkJCQkJCShlcnJjb2RlKHN0 +YXR1cyksDQorIAkJCQkJCSBlcnJtc2coIklDVSBlcnJvcjogQ291bGQgbm90 +IG1vZGlmeSBjYXNlIikpKTsNCisgCQl9DQorIA0KKyAJCS8vIGFuZCBjb252 +ZXJ0IG1vZGlmaWVkIHV0Zi0xNiBzdHJpbmcgYmFjayB0byB0ZXh0DQorIAkJ +cmVzdWx0ID0gVUNoYXJ0b3RleHQoZGVzdCwgYnVmbGVuKTsNCisgDQorIAkJ +aWYgKGFyZ2xlbiAqIHNpemVvZihVQ2hhcikgPj0gU1RBQ0tCVUZMRU4pDQor +IAkJew0KKyAJCQlwZnJlZShzb3VyY2UpOw0KKyAJCQlwZnJlZShkZXN0KTsN +CisgCQl9DQorIAkJUEdfUkVUVVJOX1RFWFRfUChyZXN1bHQpOw0KKyAJfQ0K +KyAJZWxzZQ0KKyAjZWxzZQ0KICAjaWZkZWYgVVNFX1dJREVfVVBQRVJfTE9X +RVINCiAgCS8qDQogIAkgKglVc2Ugd2lkZSBjaGFyIGNvZGUgb25seSB3aGVu +IG1heCBlbmNvZGluZyBsZW5ndGggPiAxIGFuZCBjdHlwZSAhPSBDLg0KKioq +KioqKioqKioqKioqDQoqKiogMjU4LDI2MyAqKioqDQotLS0gNDM5LDQ0NSAt +LS0tDQogIAl9DQogIAllbHNlDQogICNlbmRpZiAgIC8qIFVTRV9XSURFX1VQ +UEVSX0xPV0VSICovDQorICNlbmRpZiAgIC8qIFVTRV9JQ1UgKi8NCiAgCXsN +CiAgCQl0ZXh0CSAgICpzdHJpbmcgPSBQR19HRVRBUkdfVEVYVF9QX0NPUFko +MCk7DQogIAkJY2hhcgkgICAqcHRyOw0KKioqKioqKioqKioqKioqDQoqKiog +MzAxLDMwNiAqKioqDQotLS0gNDgzLDU1MyAtLS0tDQogIERhdHVtDQogIGlu +aXRjYXAoUEdfRlVOQ1RJT05fQVJHUykNCiAgew0KKyAjaWZkZWYgVVNFX0lD +VQ0KKyAJLyogdXNlIElDVSBvbmx5IHdoZW4gbWF4IGVuY29kaW5nIGxlbmd0 +aCA+IG9uZSAqLw0KKyAJaWYgKHBnX2RhdGFiYXNlX2VuY29kaW5nX21heF9s +ZW5ndGgoKSA+IDEpDQorIAl7DQorIAkJdGV4dAkgICAqc3RyaW5nID0gUEdf +R0VUQVJHX1RFWFRfUCgwKTsNCisgCQl0ZXh0CSAgICpyZXN1bHQ7DQorIAkJ +VUNoYXIgICAgICAgc291cmNlYnVmW1NUQUNLQlVGTEVOXSwgZGVzdGJ1ZltT +VEFDS0JVRkxFTl07DQorIAkJVUNoYXIgICAgICAqc291cmNlLCAqZGVzdDsN +CisgCQlpbnQzMl90ICAgICBidWZsZW4sIGFyZ2xlbjsNCisgDQorIAkJVUVy +cm9yQ29kZSAgc3RhdHVzID0gVV9aRVJPX0VSUk9SOw0KKyANCisgCQlpZiAo +Y29udiA9PSBOVUxMKQ0KKyAJCXsNCisgCQkJY29udiA9IHVjbnZfb3BlbihO +VUxMLCAmc3RhdHVzKTsNCisgCQkJaWYgKFVfRkFJTFVSRShzdGF0dXMpKQ0K +KyAJCQl7DQorIAkJCQllcmVwb3J0KEVSUk9SLA0KKyAJCQkJCQkoZXJyY29k +ZShzdGF0dXMpLA0KKyAJCQkJCQkgZXJybXNnKCJJQ1UgZXJyb3I6IENvdWxk +IG5vdCBnZXQgY29udmVydGVyIGZvciBcIiVzXCIiLCB1Y252X2dldERlZmF1 +bHROYW1lKCkpKSk7DQorIAkJCX0NCisgCQl9DQorIAkJYXJnbGVuID0gVkFS +U0laRShzdHJpbmcpIC0gVkFSSERSU1o7DQorIAkJaWYgKGFyZ2xlbiAqIHNp +emVvZihVQ2hhcikgPj0gU1RBQ0tCVUZMRU4pDQorIAkJew0KKyAJCQlidWZs +ZW4gPSBhcmdsZW4gKiBzaXplb2YoVUNoYXIpICsgMTsNCisgIAkJCXNvdXJj +ZSA9IHBhbGxvYyhidWZsZW4pOw0KKyAJCQlkZXN0ID0gcGFsbG9jKGJ1Zmxl +bik7DQorIAkJfQ0KKyAJCWVsc2UNCisgCQl7DQorIAkJCWJ1ZmxlbiA9IFNU +QUNLQlVGTEVOOw0KKyAJCQlzb3VyY2UgPSBzb3VyY2VidWY7DQorIAkJCWRl +c3QgPSBkZXN0YnVmOw0KKyAJCX0NCisgCQkvLyBjb252ZXJ0IHRvIFVURi0x +Ng0KKyAJCXVjbnZfdG9VQ2hhcnMoY29udiwgc291cmNlLCBidWZsZW4sIFZB +UkRBVEEoc3RyaW5nKSwgYXJnbGVuLCAmc3RhdHVzKTsNCisgCQlpZiAoVV9G +QUlMVVJFKHN0YXR1cykpDQorIAkJew0KKyAJCQllcmVwb3J0KEVSUk9SLA0K +KyAJCQkJCQkoZXJyY29kZShzdGF0dXMpLA0KKyAJCQkJCQkgZXJybXNnKCJJ +Q1UgZXJyb3I6IENvdWxkIG5vdCBjb252ZXJ0IHN0cmluZyIpKSk7DQorIAkJ +fQ0KKyANCisgCQkvLyBydW4gZGVzaXJlZCBmdW5jdGlvbg0KKyAJCWJ1Zmxl +biA9IHVfc3RyVG9UaXRsZShkZXN0LCBidWZsZW4sIHNvdXJjZSwgLTEsIE5V +TEwsIE5VTEwsICZzdGF0dXMpOw0KKyAJCWlmIChVX0ZBSUxVUkUoc3RhdHVz +KSkNCisgCQl7DQorIAkJCWVyZXBvcnQoRVJST1IsDQorIAkJCQkJCShlcnJj +b2RlKHN0YXR1cyksDQorIAkJCQkJCSBlcnJtc2coIklDVSBlcnJvcjogQ291 +bGQgbm90IG1vZGlmeSBjYXNlIikpKTsNCisgCQl9DQorIA0KKyAJCS8vIGFu +ZCBjb252ZXJ0IG1vZGlmaWVkIHV0Zi0xNiBzdHJpbmcgYmFjayB0byB0ZXh0 +DQorIAkJcmVzdWx0ID0gVUNoYXJ0b3RleHQoZGVzdCwgYnVmbGVuKTsNCisg +DQorIAkJaWYgKGFyZ2xlbiAqIHNpemVvZihVQ2hhcikgPj0gU1RBQ0tCVUZM +RU4pDQorIAkJew0KKyAJCQlwZnJlZShzb3VyY2UpOw0KKyAJCQlwZnJlZShk +ZXN0KTsNCisgCQl9DQorIAkJUEdfUkVUVVJOX1RFWFRfUChyZXN1bHQpOw0K +KyAJfQ0KKyAJZWxzZQ0KKyAjZWxzZQ0KICAjaWZkZWYgVVNFX1dJREVfVVBQ +RVJfTE9XRVINCiAgCS8qDQogIAkgKglVc2Ugd2lkZSBjaGFyIGNvZGUgb25s +eSB3aGVuIG1heCBlbmNvZGluZyBsZW5ndGggPiAxIGFuZCBjdHlwZSAhPSBD +Lg0KKioqKioqKioqKioqKioqDQoqKiogMzM0LDMzOSAqKioqDQotLS0gNTgx +LDU4NyAtLS0tDQogIAl9DQogIAllbHNlDQogICNlbmRpZiAgIC8qIFVTRV9X +SURFX1VQUEVSX0xPV0VSICovDQorICNlbmRpZiAgIC8qIFVTRV9JQ1UgKi8N +CiAgCXsNCiAgCQl0ZXh0CSAgICpzdHJpbmcgPSBQR19HRVRBUkdfVEVYVF9Q +X0NPUFkoMCk7DQogIAkJaW50CQkJd2FzYWxudW0gPSAwOw0KSW5kZXg6IHNy +Yy9iYWNrZW5kL3V0aWxzL2FkdC92YXJsZW5hLmMNCj09PT09PT09PT09PT09 +PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 +PT09PT09PT0NClJDUyBmaWxlOiAvcHJvamVjdHMvY3Zzcm9vdC9wZ3NxbC9z +cmMvYmFja2VuZC91dGlscy9hZHQvdmFybGVuYS5jLHYNCnJldHJpZXZpbmcg +cmV2aXNpb24gMS4xMzANCmRpZmYgLWMgLXIxLjEzMCB2YXJsZW5hLmMNCioq +KiBzcmMvYmFja2VuZC91dGlscy9hZHQvdmFybGVuYS5jCTI5IEp1bCAyMDA1 +IDAzOjE3OjU1IC0wMDAwCTEuMTMwDQotLS0gc3JjL2JhY2tlbmQvdXRpbHMv +YWR0L3ZhcmxlbmEuYwkzMCBKdWwgMjAwNSAxNzo0NjozNCAtMDAwMA0KKioq +KioqKioqKioqKioqDQoqKiogMzAsMzUgKioqKg0KLS0tIDMwLDQxIC0tLS0N +CiAgI2luY2x1ZGUgInV0aWxzL3BnX2xvY2FsZS5oIg0KICAjaW5jbHVkZSAi +cmVnZXgvcmVnZXguaCINCiAgDQorICNpZmRlZiBVU0VfSUNVDQorICNpbmNs +dWRlIDx1bmljb2RlL3V0eXBlcy5oPiAgIC8qIEJhc2ljIElDVSBkYXRhIHR5 +cGVzICovDQorICNpbmNsdWRlIDx1bmljb2RlL3VjbnYuaD4gICAgIC8qIEMg +ICBDb252ZXJ0ZXIgQVBJICAgICovDQorICNpbmNsdWRlIDx1bmljb2RlL3Vj +b2wuaD4NCisgI2luY2x1ZGUgPHVuaWNvZGUvdWxvYy5oPg0KKyAjZW5kaWYg +LyogVVNFX0lDVSAqLw0KICANCiAgdHlwZWRlZiBzdHJ1Y3QgdmFybGVuYSB1 +bmtub3duOw0KICANCioqKioqKioqKioqKioqKg0KKioqIDg0NCw4NzQgKioq +Kg0KICANCiAgCWlmICghbGNfY29sbGF0ZV9pc19jKCkpDQogIAl7DQohIAkJ +Y2hhcgkJYTFidWZbU1RBQ0tCVUZMRU5dOw0KISAJCWNoYXIJCWEyYnVmW1NU +QUNLQlVGTEVOXTsNCiEgCQljaGFyCSAgICphMXAsDQohIAkJCQkgICAqYTJw +Ow0KICANCiEgCQlpZiAobGVuMSA+PSBTVEFDS0JVRkxFTikNCiEgCQkJYTFw +ID0gKGNoYXIgKikgcGFsbG9jKGxlbjEgKyAxKTsNCiEgCQllbHNlDQohIAkJ +CWExcCA9IGExYnVmOw0KISAJCWlmIChsZW4yID49IFNUQUNLQlVGTEVOKQ0K +ISAJCQlhMnAgPSAoY2hhciAqKSBwYWxsb2MobGVuMiArIDEpOw0KICAJCWVs +c2UNCiEgCQkJYTJwID0gYTJidWY7DQogIA0KISAJCW1lbWNweShhMXAsIGFy +ZzEsIGxlbjEpOw0KISAJCWExcFtsZW4xXSA9ICdcMCc7DQohIAkJbWVtY3B5 +KGEycCwgYXJnMiwgbGVuMik7DQohIAkJYTJwW2xlbjJdID0gJ1wwJzsNCiEg +DQohIAkJcmVzdWx0ID0gc3RyY29sbChhMXAsIGEycCk7DQohIA0KISAJCWlm +IChsZW4xID49IFNUQUNLQlVGTEVOKQ0KISAJCQlwZnJlZShhMXApOw0KISAJ +CWlmIChsZW4yID49IFNUQUNLQlVGTEVOKQ0KISAJCQlwZnJlZShhMnApOw0K +ICAJfQ0KICAJZWxzZQ0KICAJew0KLS0tIDg1MCw5ODYgLS0tLQ0KICANCiAg +CWlmICghbGNfY29sbGF0ZV9pc19jKCkpDQogIAl7DQohICNpZmRlZiBVU0Vf +SUNVDQohICNkZWZpbmUgVVNUQUNLQlVGTEVOCQlTVEFDS0JVRkxFTiAvIHNp +emVvZihVQ2hhcikNCiEgCQlpZiAocGdfZGF0YWJhc2VfZW5jb2RpbmdfbWF4 +X2xlbmd0aCgpID4gMSkNCiEgCQl7DQohIAkJCVVDaGFyCQlhMWJ1ZltVU1RB +Q0tCVUZMRU5dLA0KISAJCSAgICAgICAgIAkJYTJidWZbVVNUQUNLQlVGTEVO +XTsNCiEgCQkJaW50CQkJYTFsZW4gPSBVU1RBQ0tCVUZMRU4sDQohIAkJCSAg +CQkJYTJsZW4gPSBVU1RBQ0tCVUZMRU47CQ0KISAJCQlVQ2hhcgkgICAqYTFw +LA0KISAJCQkgICAgICAgICAgICphMnA7DQohIA0KISAJCQlzdGF0aWMgVUNv +bGxhdG9yICogY29sbGF0b3IgPSBOVUxMOw0KISAJCQlzdGF0aWMgVUNvbnZl +cnRlciAqIGNvbnYgPSBOVUxMOw0KISAJCQlVRXJyb3JDb2RlICBzdGF0dXMg +PSBVX1pFUk9fRVJST1I7DQogIA0KISAJCQlpZiAoY29udiA9PSBOVUxMKQ0K +ISAJCQl7DQohIAkJCQljb252ID0gdWNudl9vcGVuKE5VTEwsICZzdGF0dXMp +Ow0KISAJCQkJaWYgKFVfRkFJTFVSRShzdGF0dXMpIHx8IGNvbnYgPT0gTlVM +TCkNCiEgCQkJCXsNCiEgCQkJCQllcmVwb3J0KEVSUk9SLA0KISAJCQkJCQkJ +KGVycmNvZGUoc3RhdHVzKSwNCiEgCQkJCQkJCSBlcnJtc2coIklDVSBlcnJv +cjogdmFybGVuYS5jLCBjb3VsZCBub3QgZ2V0IGNvbnZlcnRlciBmb3IgXCIl +c1wiIiwgdWNudl9nZXREZWZhdWx0TmFtZSgpKSkpOw0KISAJCQkJfQ0KISAJ +CQl9DQohIA0KISAJCQkvKiBXZSBrZWVwIGEgc3RhdGljIGNvbGxhdG9yICJm +b3JldmVyIiwgc2luY2UgaXQgaXMgaGFyZA0KISAJCQkgKiBjb2RlZCBpbnRv +IHRoZSBkYXRhYmFzZSBjbHVzdGVyIGF0IGluaXRkYiB0aW1lDQohIAkJCSAq +IGFueXdheS4gQ3JlYXRlIGl0IGZpcnN0IHRpbWUgd2UgZ2V0IGhlcmUuICov +DQohIAkJCWlmIChjb2xsYXRvciA9PSBOVUxMKQ0KISAJCQl7DQohIAkJCQkv +KiBFeHBlY3QgTENfQ09MTEFURSB0byBiZSBzZXQgdG8gc29tZXRoaW5nIHRo +YXQgSUNVDQohIAkJCQkgKiB3aWxsIHVuZGVyc3RhbmQuIFRoaXMgaXMgcXVp +dGUgcHJvYmFibGUsIHNpbmNlIElDVQ0KISAJCQkJICogZG9lcyBhIGxvdCBv +ZiBoZXVyaXN0aWNzIHdpdGggdGhpcyBhcmd1bWVudC4gSSdkDQohIAkJCQkg +KiByYXRoZXIgc2V0IHRoaXMgaW4geGxvZy5jLCBidXQgaXQgc2VlbXMgSUNV +IGZvcmdldHMNCiEgCQkJCSAqIGl0Pz8/ICovDQohICNpZm5kZWYgV0lOMzIN +CiEgCQkJCXVsb2Nfc2V0RGVmYXVsdChzZXRsb2NhbGUoTENfQ09MTEFURSwg +TlVMTCksICZzdGF0dXMpOw0KISAjZWxzZQ0KISAJCQkJLyogV2luMzIgbG9j +YWxlIG5hbWVzIGFyZSBjb21wbGV0ZWx5IGRpZmZlcmVudCBmcm9tIHdoYXQg +SUNVIGV4cGVjdHMsIHNvIA0KISAJCQkJICAgd2UgbmVlZCB0byBkbyBzb21l +IGNvbnZlcnNpb24gKi8NCiEgCQkJCXVsb2Nfc2V0RGVmYXVsdChwZ3dpbjMy +X2xvY2FsZW1hcChzZXRsb2NhbGUoTENfQ09MTEFURSwgTlVMTCkpLCAmc3Rh +dHVzKTsNCiEgI2VuZGlmDQohIAkJCQlpZihVX0ZBSUxVUkUoc3RhdHVzKSkN +CiEgCQkJCXsNCiEgCQkJCQllcmVwb3J0KFdBUk5JTkcsDQohIAkJCQkJCQko +ZXJyY29kZShzdGF0dXMpLA0KISAJCQkJCQkJIGVycm1zZygiSUNVIEVycm9y +OiB2YXJsZW5hLmMsIGNvdWxkIG5vdCBzZXQgZGVmYXVsdCBsY19jb2xsYXRl +IikpKTsNCiEgCQkJCX0NCiEgCQkJCWNvbGxhdG9yID0gdWNvbF9vcGVuKE5V +TEwsICZzdGF0dXMpOw0KISAJCQkJaWYgKFVfRkFJTFVSRShzdGF0dXMpKQ0K +ISAJCQkJew0KISAJCQkJCWVyZXBvcnQoV0FSTklORywNCiEgCQkJCQkJCShl +cnJjb2RlKHN0YXR1cyksDQohIAkJCQkJCQkgZXJybXNnKCJJQ1UgRXJyb3I6 +IHZhcmxlbmEuYywgY291bGQgbm90IG9wZW4gY29sbGF0b3IiKSkpOw0KISAJ +CQkJfQ0KISAJCQl9DQohIAkJCQ0KISAJCQlpZiAobGVuMSA+PSBVU1RBQ0tC +VUZMRU4gLyBzaXplb2YoVUNoYXIpKQ0KISAJCQl7DQohIAkJCQlhMWxlbiA9 +IGxlbjEgKiBzaXplb2YoVUNoYXIpICsgMjsNCiEgCQkJCWExcCA9IChVQ2hh +ciAqKSBwYWxsb2MoYTFsZW4pOwkNCiEgCQkJfQ0KISAJCQllbHNlDQohIAkJ +CQlhMXAgPSBhMWJ1ZjsNCiEgDQohIAkJCWlmIChsZW4yID49IFVTVEFDS0JV +RkxFTiAvIHNpemVvZihVQ2hhcikpDQohIAkJCXsNCiEgCQkJCWEybGVuID0g +bGVuMiAqIHNpemVvZihVQ2hhcikgKyAyOw0KISAJCQkJYTJwID0gKFVDaGFy +ICopIHBhbGxvYyhhMmxlbik7DQohIAkJCX0NCiEgCQkJZWxzZQ0KISAJCQkJ +YTJwID0gYTJidWY7DQohIA0KISAJCQl1Y252X3RvVUNoYXJzKGNvbnYsIGEx +cCwgYTFsZW4sIGFyZzEsIGxlbjEsICZzdGF0dXMpOw0KISAJCQlpZihVX0ZB +SUxVUkUoc3RhdHVzKSkNCiEgCQkJew0KISAJCQkJZXJlcG9ydChXQVJOSU5H +LA0KISAJCQkJCQkoZXJyY29kZShzdGF0dXMpLA0KISAJCQkJCQkgZXJybXNn +KCJJQ1UgRXJyb3I6IHZhcmxlbmEuYywgY291bGQgbm90IGNvbnZlcnQgdG8g +VUNoYXJzIikpKTsNCiEgCQkJfQ0KISAJCQl1Y252X3RvVUNoYXJzKGNvbnYs +IGEycCwgYTJsZW4sIGFyZzIsIGxlbjIsICZzdGF0dXMpOw0KISAJCQlpZihV +X0ZBSUxVUkUoc3RhdHVzKSkNCiEgCQkJew0KISAJCQkJZXJlcG9ydChXQVJO +SU5HLA0KISAJCQkJCQkoZXJyY29kZShzdGF0dXMpLA0KISAJCQkJCQkgZXJy +bXNnKCJJQ1UgRXJyb3I6IHZhcmxlbmEuYywgY291bGQgbm90IGNvbnZlcnQg +dG8gVUNoYXJzIikpKTsNCiEgCQkJfQ0KISANCiEgCQkJcmVzdWx0ID0gdWNv +bF9zdHJjb2xsKGNvbGxhdG9yLCBhMXAsIC0xLCBhMnAsIC0xKTsNCiEgCQkJ +aWYoVV9GQUlMVVJFKHN0YXR1cykpDQohIAkJCXsNCiEgCQkJCWVyZXBvcnQo +V0FSTklORywNCiEgCQkJCQkJKGVycmNvZGUoc3RhdHVzKSwNCiEgCQkJCQkJ +IGVycm1zZygiSUNVIEVycm9yOiB2YXJsZW5hLmMsIGNvdWxkIG5vdCBjb2xs +YXRlIikpKTsNCiEgCQkJfQ0KISANCiEgCQkJaWYgKGxlbjEgKiBzaXplb2Yo +VUNoYXIpID49IFVTVEFDS0JVRkxFTikNCiEgCQkJCXBmcmVlKGExcCk7DQoh +IAkJCWlmIChsZW4yICogc2l6ZW9mKFVDaGFyKSA+PSBVU1RBQ0tCVUZMRU4p +DQohIAkJCQlwZnJlZShhMnApOw0KISAJCX0NCiAgCQllbHNlDQohICNlbmRp +ZiAvKiBVU0VfSUNVICovDQohIAkJew0KISAJCQljaGFyCQlhMWJ1ZltTVEFD +S0JVRkxFTl07DQohIAkJCWNoYXIJCWEyYnVmW1NUQUNLQlVGTEVOXTsNCiEg +CQkJY2hhcgkgICAqYTFwLA0KISAJCQkJCSAgICphMnA7DQogIA0KISAJCQlp +ZiAobGVuMSA+PSBTVEFDS0JVRkxFTikNCiEgCQkJCWExcCA9IChjaGFyICop +IHBhbGxvYyhsZW4xICsgMSk7DQohIAkJCWVsc2UNCiEgCQkJCWExcCA9IGEx +YnVmOw0KISAJCQlpZiAobGVuMiA+PSBTVEFDS0JVRkxFTikNCiEgCQkJCWEy +cCA9IChjaGFyICopIHBhbGxvYyhsZW4yICsgMSk7DQohIAkJCWVsc2UNCiEg +CQkJCWEycCA9IGEyYnVmOw0KISAJCQkNCiEgCQkJbWVtY3B5KGExcCwgYXJn +MSwgbGVuMSk7DQohIAkJCWExcFtsZW4xXSA9ICdcMCc7DQohIAkJCW1lbWNw +eShhMnAsIGFyZzIsIGxlbjIpOw0KISAJCQlhMnBbbGVuMl0gPSAnXDAnOw0K +ISAJCQkNCiEgCQkJcmVzdWx0ID0gc3RyY29sbChhMXAsIGEycCk7DQohIAkJ +CQ0KISAJCQlpZiAobGVuMSA+PSBTVEFDS0JVRkxFTikNCiEgCQkJCXBmcmVl +KGExcCk7DQohIAkJCWlmIChsZW4yID49IFNUQUNLQlVGTEVOKQ0KISAJCQkJ +cGZyZWUoYTJwKTsNCiEgCQl9DQogIAl9DQogIAllbHNlDQogIAl7DQpJbmRl +eDogc3JjL2JhY2tlbmQvdXRpbHMvbWIvZW5jbmFtZXMuYw0KPT09PT09PT09 +PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 +PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9wcm9qZWN0cy9jdnNyb290L3Bn +c3FsL3NyYy9iYWNrZW5kL3V0aWxzL21iL2VuY25hbWVzLmMsdg0KcmV0cmll +dmluZyByZXZpc2lvbiAxLjI1DQpkaWZmIC1jIC1yMS4yNSBlbmNuYW1lcy5j +DQoqKiogc3JjL2JhY2tlbmQvdXRpbHMvbWIvZW5jbmFtZXMuYwkxNCBNYXIg +MjAwNSAxODozMToyMCAtMDAwMAkxLjI1DQotLS0gc3JjL2JhY2tlbmQvdXRp +bHMvbWIvZW5jbmFtZXMuYwkyOCBKdWwgMjAwNSAxNzoxNjo1MiAtMDAwMA0K +KioqKioqKioqKioqKioqDQoqKiogMzc1LDM4MCAqKioqDQotLS0gMzc1LDQ5 +NiAtLS0tDQogIAl9DQogIH07DQogIA0KKyAjaWZkZWYgVVNFX0lDVQ0KKyAv +Kg0KKyAgKiBUcnkgdG8gbWFwIG1vc3QgaW50ZXJuYWwgY2hhcmFjdGVyIGVu +Y29kaW5ncyB0byB0aGUgcHJvcGVyIGFuZA0KKyAgKiBwcmVmZXJyZWQgSUFO +QSBzdHJpbmcuIFVzZSB0aGlzIGluIG1idXRpbHMuYyB0byBmZWVkIElDVSBp +bmZvIGFib3V0DQorICAqIHRoZSBkYXRhYmFzZSdzIGNoYXJhY3RlciBlbmNv +ZGluZy4NCisgICoNCisgICogUGFsbGUgR2lyZ2Vuc29obiwgMjAwNQ0KKyAg +Ki8NCisgDQorIHBnX2VuYzJuYW1lIHBnX2VuYzJpYW5hbmFtZV90YmxbXSA9 +DQorIHsNCisgCXsNCisgCQkiVVMtQVNDSUkiLCBQR19TUUxfQVNDSUkNCisg +CX0sDQorIAl7DQorIAkJIkVVQy1KUCIsIFBHX0VVQ19KUA0KKyAJfSwNCisg +CXsNCisgCQkiR0IyMzEyIiwgUEdfRVVDX0NODQorIAl9LA0KKyAJew0KKyAJ +CSJFVUMtS1IiLCBQR19FVUNfS1INCisgCX0sDQorIAl7DQorIAkJIklTTy0y +MDIyLUNOIiwgUEdfRVVDX1RXDQorIAl9LA0KKyAJew0KKyAJCSJLU19DXzU2 +MDEtMTk4NyIsIFBHX0pPSEFCICAvKiBlaXRoZXIgS1NfQ181NjAxLTE5ODcg +b3IgSVNPLTIwMjItS1IgPz8/ICovDQorIAl9LA0KKyAJew0KKyAJCSJVVEYt +OCIsIFBHX1VURjgNCisgCX0sDQorIAl7DQorIAkJIk1VTEVfSU5URVJOQUwi +LCBQR19NVUxFX0lOVEVSTkFMICAvKiBpcyBub3QgZm9yIHJlYWwgKi8NCisg +CX0sDQorIAl7DQorIAkJIklTTy04ODU5LTEiLCBQR19MQVRJTjENCisgCX0s +DQorIAl7DQorIAkJIklTTy04ODU5LTIiLCBQR19MQVRJTjINCisgCX0sDQor +IAl7DQorIAkJIklTTy04ODU5LTMiLCBQR19MQVRJTjMNCisgCX0sDQorIAl7 +DQorIAkJIklTTy04ODU5LTQiLCBQR19MQVRJTjQNCisgCX0sDQorIAl7DQor +IAkJIklTTy04ODU5LTkiLCBQR19MQVRJTjUNCisgCX0sDQorIAl7DQorIAkJ +IklTTy04ODU5LTEwIiwgUEdfTEFUSU42DQorIAl9LA0KKyAJew0KKyAJCSJJ +U08tODg1OS0xMyIsIFBHX0xBVElONw0KKyAJfSwNCisgCXsNCisgCQkiSVNP +LTg4NTktMTQiLCBQR19MQVRJTjgNCisgCX0sDQorIAl7DQorIAkJIklTTy04 +ODU5LTE1IiwgUEdfTEFUSU45DQorIAl9LA0KKyAJew0KKyAJCSJJU08tODg1 +OS0xNiIsIFBHX0xBVElOMTANCisgCX0sDQorIAl7DQorIAkJIndpbmRvd3Mt +MTI1NiIsIFBHX1dJTjEyNTYNCisgCX0sDQorIAl7DQorIAkJIndpbmRvd3Mt +MTI1OCIsIFBHX1dJTjEyNTgNCisgCX0sDQorIAl7DQorIAkJIndpbmRvd3Mt +ODc0IiwgUEdfV0lOODc0DQorIAl9LA0KKyAJew0KKyAJCSJLT0k4LVIiLCBQ +R19LT0k4Ug0KKyAJfSwNCisgCXsNCisgCQkid2luZG93cy0xMjUxIiwgUEdf +V0lOMTI1MQ0KKyAJfSwNCisgCXsNCisgCQkiSUJNODY2IiwgUEdfV0lOODY2 +DQorIAl9LA0KKyAJew0KKyAJCSJJU08tODg1OS01IiwgUEdfSVNPXzg4NTlf +NQ0KKyAJfSwNCisgCXsNCisgCQkiSVNPLTg4NTktNiIsIFBHX0lTT184ODU5 +XzYNCisgCX0sDQorIAl7DQorIAkJIklTTy04ODU5LTciLCBQR19JU09fODg1 +OV83DQorIAl9LA0KKyAJew0KKyAJCSJJU08tODg1OS04IiwgUEdfSVNPXzg4 +NTlfOA0KKyAJfSwNCisgCXsNCisgCQkid2luZG93cy0xMjUwIiwgUEdfV0lO +MTI1MA0KKyAJfSwNCisgCXsNCisgCQkiU2hpZnRfSklTIiwgUEdfU0pJUw0K +KyAJfSwNCisgCXsNCisgCQkiQmlnNSIsIFBHX0JJRzUNCisgCX0sDQorIAl7 +DQorIAkJIkdCSyIsIFBHX0dCSw0KKyAJfSwNCisgCXsNCisgCQkiY3A5NDki +LCBQR19VSEMNCisgCX0sDQorIAl7DQorIAkJIkdCMTgwMzAiLCBQR19HQjE4 +MDMwDQorIAl9DQorIH07DQorICNlbmRpZiAvKiBVU0VfSUNVICovDQorIA0K +ICAvKiAtLS0tLS0tLS0tDQogICAqIEVuY29kaW5nIGNoZWNrcywgZm9yIGVy +cm9yIHJldHVybnMgLTEgZWxzZSBlbmNvZGluZyBpZA0KICAgKiAtLS0tLS0t +LS0tDQpJbmRleDogc3JjL2JhY2tlbmQvdXRpbHMvbWIvbWJ1dGlscy5jDQo9 +PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 +PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL3Byb2plY3RzL2N2 +c3Jvb3QvcGdzcWwvc3JjL2JhY2tlbmQvdXRpbHMvbWIvbWJ1dGlscy5jLHYN +CnJldHJpZXZpbmcgcmV2aXNpb24gMS41MA0KZGlmZiAtYyAtcjEuNTAgbWJ1 +dGlscy5jDQoqKiogc3JjL2JhY2tlbmQvdXRpbHMvbWIvbWJ1dGlscy5jCTEw +IEp1bCAyMDA1IDIxOjEzOjU5IC0wMDAwCTEuNTANCi0tLSBzcmMvYmFja2Vu +ZC91dGlscy9tYi9tYnV0aWxzLmMJMjggSnVsIDIwMDUgMTY6MzY6NTQgLTAw +MDANCioqKioqKioqKioqKioqKg0KKioqIDE1LDIwICoqKioNCi0tLSAxNSwy +MyAtLS0tDQogICNpbmNsdWRlICJ1dGlscy9tZW11dGlscy5oIg0KICAjaW5j +bHVkZSAidXRpbHMvc3lzY2FjaGUuaCINCiAgI2luY2x1ZGUgImNhdGFsb2cv +bmFtZXNwYWNlLmgiDQorICNpZmRlZiBVU0VfSUNVDQorICNpbmNsdWRlIDx1 +bmljb2RlL3VjbnYuaD4NCisgI2VuZGlmIC8qIFVTRV9JQ1UgKi8NCiAgDQog +IC8qDQogICAqIFdlIGhhbmRsZSBmb3IgYWN0dWFsIEZFIGFuZCBCRSBlbmNv +ZGluZyBzZXR0aW5nIGVuY29kaW5nLWlkZW50aWZpY2F0b3INCioqKioqKioq +KioqKioqKg0KKioqIDU3Niw1ODEgKioqKg0KLS0tIDU3OSw1ODcgLS0tLQ0K +ICANCiAgCURhdGFiYXNlRW5jb2RpbmcgPSAmcGdfZW5jMm5hbWVfdGJsW2Vu +Y29kaW5nXTsNCiAgCUFzc2VydChEYXRhYmFzZUVuY29kaW5nLT5lbmNvZGlu +ZyA9PSBlbmNvZGluZyk7DQorICNpZmRlZiBVU0VfSUNVDQorIAl1Y252X3Nl +dERlZmF1bHROYW1lKCgmcGdfZW5jMmlhbmFuYW1lX3RibFtlbmNvZGluZ10p +LT5uYW1lKTsNCisgI2VuZGlmDQogIH0NCiAgDQogIHZvaWQNCkluZGV4OiBz +cmMvaW5jbHVkZS9wZ19jb25maWcuaC5pbg0KPT09PT09PT09PT09PT09PT09 +PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 +PT09PQ0KUkNTIGZpbGU6IC9wcm9qZWN0cy9jdnNyb290L3Bnc3FsL3NyYy9p +bmNsdWRlL3BnX2NvbmZpZy5oLmluLHYNCnJldHJpZXZpbmcgcmV2aXNpb24g +MS44Ng0KZGlmZiAtYyAtcjEuODYgcGdfY29uZmlnLmguaW4NCioqKiBzcmMv +aW5jbHVkZS9wZ19jb25maWcuaC5pbgkxIEp1bCAyMDA1IDE4OjE3OjMxIC0w +MDAwCTEuODYNCi0tLSBzcmMvaW5jbHVkZS9wZ19jb25maWcuaC5pbgkyOCBK +dWwgMjAwNSAxNjozNjo1NCAtMDAwMA0KKioqKioqKioqKioqKioqDQoqKiog +NjQyLDY0NyAqKioqDQotLS0gNjQyLDY1MCAtLS0tDQogIC8qIERlZmluZSB0 +byBidWlsZCB3aXRoIChPcGVuKVNTTCBzdXBwb3J0LiAoLS13aXRoLW9wZW5z +c2wpICovDQogICN1bmRlZiBVU0VfU1NMDQogIA0KKyAvKiBEZWZpbmUgdG8g +YnVpbGQgd2l0aCBJQ1Ugc3VwcG9ydC4gKC0td2l0aC1pY3UpICovDQorICN1 +bmRlZiBVU0VfSUNVDQorIA0KICAvKiBEZWZpbmUgdG8gc2VsZWN0IFN5c1Yt +c3R5bGUgc2VtYXBob3Jlcy4gKi8NCiAgI3VuZGVmIFVTRV9TWVNWX1NFTUFQ +SE9SRVMNCiAgDQpJbmRleDogc3JjL2luY2x1ZGUvbWIvcGdfd2NoYXIuaA0K +PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 +PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9wcm9qZWN0cy9j +dnNyb290L3Bnc3FsL3NyYy9pbmNsdWRlL21iL3BnX3djaGFyLmgsdg0KcmV0 +cmlldmluZyByZXZpc2lvbiAxLjU5DQpkaWZmIC1jIC1yMS41OSBwZ193Y2hh +ci5oDQoqKiogc3JjL2luY2x1ZGUvbWIvcGdfd2NoYXIuaAkxNSBKdW4gMjAw +NSAwMDoxNTowOCAtMDAwMAkxLjU5DQotLS0gc3JjL2luY2x1ZGUvbWIvcGdf +d2NoYXIuaAkyOCBKdWwgMjAwNSAxNjozNjo1NCAtMDAwMA0KKioqKioqKioq +KioqKioqDQoqKiogMjM1LDI0MCAqKioqDQotLS0gMjM1LDI0MSAtLS0tDQog +IH0gcGdfZW5jMm5hbWU7DQogIA0KICBleHRlcm4gcGdfZW5jMm5hbWUgcGdf +ZW5jMm5hbWVfdGJsW107DQorIGV4dGVybiBwZ19lbmMybmFtZSBwZ19lbmMy +aWFuYW5hbWVfdGJsW107DQogIA0KICBleHRlcm4gcGdfZW5jbmFtZSAqcGdf +Y2hhcl90b19lbmNuYW1lX3N0cnVjdChjb25zdCBjaGFyICpuYW1lKTsNCiAg +DQpJbmRleDogc3JjL2luY2x1ZGUvcG9ydC93aW4zMi5oDQo9PT09PT09PT09 +PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 +PT09PT09PT09PT09DQpSQ1MgZmlsZTogL3Byb2plY3RzL2N2c3Jvb3QvcGdz +cWwvc3JjL2luY2x1ZGUvcG9ydC93aW4zMi5oLHYNCnJldHJpZXZpbmcgcmV2 +aXNpb24gMS40Ng0KZGlmZiAtYyAtcjEuNDYgd2luMzIuaA0KKioqIHNyYy9p +bmNsdWRlL3BvcnQvd2luMzIuaAkxNiBKdW4gMjAwNSAxNzo1Mzo1NCAtMDAw +MAkxLjQ2DQotLS0gc3JjL2luY2x1ZGUvcG9ydC93aW4zMi5oCTMwIEp1bCAy +MDA1IDE3OjM5OjM2IC0wMDAwDQoqKioqKioqKioqKioqKioNCioqKiAyNTYs +MjU4ICoqKioNCi0tLSAyNTYsMjYxIC0tLS0NCiAgDQogIC8qIGluIGJhY2tl +bmQvcG9ydC93aW4zMi9lcnJvci5jICovDQogIGV4dGVybiB2b2lkIF9kb3Nt +YXBlcnIodW5zaWduZWQgbG9uZyk7DQorIA0KKyAvKiBpbiBiYWNrZW5kL3Bv +cnQvd2luMzIvbG9jYWxlbWFwLmMgKi8NCisgZXh0ZXJuIGNoYXIgKnBnd2lu +MzJfbG9jYWxlbWFwKGNoYXIgKndpbmxvY2FsZSk7DQo= + +------_=_NextPart_001_01C5993C.1E1CB100 +Content-Type: application/octet-stream; + name="localemap.pl" +Content-Transfer-Encoding: base64 +Content-Description: localemap.pl +Content-Disposition: attachment; + filename="localemap.pl" + +IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj +IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMgbG9jYWxlbWFwLnBs +IC0tIEJ1aWxkIGxvY2FsZSBtYXAgYmFzZWQgb24gc291cmNlIGRhdGEgZmls +ZXMNCiMNCiMgQ29weXJpZ2h0IChjKSAyMDA1LCBQb3N0Z3JlU1FMIEdsb2Jh +bCBEZXZlbG9wbWVudCBHcm91cA0KIw0KIyAkUG9zdGdyZVNRTCQNCiMjIyMj +IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj +IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojDQojIFRoZSBmaWxlIGlzbzYz +OSBjb250YWlucyBJU08tNjM5IGxhbmd1YWdlIGNvZGVzLCBjdXQtYW5kLXBh +c3RlIGZyb20NCiMgaHR0cDovL3d3dy53My5vcmcvV0FJL0VSL0lHL2VydC9p +c282MzkuaHRtLg0KIw0KIyBUaGUgZmlsZSBpc28zMTY2IGNvbnRhaW5zIElT +Ty0zMTY2IGNvdW50cnkgY29kZXMsIGN1dC1hbmQtcGFzdGUgZnJvbQ0KIyBo +dHRwOi8vd3d3Lm9hc2lzLW9wZW4ub3JnL2NvdmVyL2NvdW50cnkzMTY2Lmh0 +bWwsDQojDQoNCm9wZW4oSSwiaXNvNjM5IikgfHwgZGllICJDb3VsZCBub3Qg +b3BlbiBpc282MzlcbiI7DQp3aGlsZSAoPEk+KSB7DQoJY2hvbXA7DQoJZGll +ICJNYWxmb3JtYXR0ZWQgbGluZSBpbiBpc282MzkiIHVubGVzcyAvXihbQS1a +XXsyfSkgXCIoLispXCIkLzsNCgkkY29kZSA9IGxjICQxOw0KCSRsYW5nID0g +bGMgJDI7DQoJaWYgKCRsYW5nID1+IC9eKC4rKVwiIC8pIHsgJGxhbmcgPSAk +MTsgfQ0KCSRpc282Mzl7JGxhbmd9PSRjb2RlOw0KfQ0KY2xvc2UoSSk7DQoN +Cm9wZW4oSSwiaXNvMzE2NiIpIHx8IGRpZSAiQ291bGQgbm90IG9wZW4gaXNv +MzE2NlxuIjsNCndoaWxlICg8ST4pIHsNCgljaG9tcDsNCglkaWUgIk1hbGZv +cm1hdHRlZCBsaW5lIGluIGlzbzMxNjYiIHVubGVzcyAvXihbQS1aXXsyfSlc +cysoLispJC87DQoJJGNvZGUgPSBsYyAkMTsNCgkkY291bnRyeSA9IGxjICQy +Ow0KCSRpc28zMTY2eyRjb3VudHJ5fSA9ICRjb2RlOw0KfQ0KY2xvc2UoSSk7 +DQoNCnByaW50IDw8RU9GOw0KdHlwZWRlZiBzdHJ1Y3Qgew0KCWNoYXIgKmtl +eTsNCgljaGFyICp2YWw7DQp9IF9rZXl2YWw7DQoNCnN0YXRpYyBfa2V5dmFs +IGlzbzYzOVtdID0gew0KRU9GDQpmb3IgJGsgKHNvcnQga2V5cyAlaXNvNjM5 +KSB7DQoJcHJpbnQgIiB7XCIka1wiLFwiJGlzbzYzOXska31cIn0sXG4iOw0K +fQ0KcHJpbnQgIiB7TlVMTCxOVUxMfVxufTtcblxuIjsNCg0KcHJpbnQgInN0 +YXRpYyBfa2V5dmFsIGlzbzMxNjZbXSA9IHtcbiI7DQpmb3IgJGsgKHNvcnQg +a2V5cyAlaXNvMzE2Nikgew0KCXByaW50ICIge1wiJGtcIixcIiRpc28zMTY2 +eyRrfVwifSxcbiI7DQp9DQoNCnByaW50ICIge05VTEwsTlVMTH1cbn07XG5c +biI7DQo= + +------_=_NextPart_001_01C5993C.1E1CB100 +Content-Type: application/octet-stream; + name="localemap.c" +Content-Transfer-Encoding: base64 +Content-Description: localemap.c +Content-Disposition: attachment; + filename="localemap.c" + +LyoNCiAqIGxvY2FsZW1hcCAtIG1hcCB3aW4zMiBsb2NhbGUgbmFtZXMgdG8g +SUNVIHN0YW5kYXJkIG5hbWVzDQogKg0KICogQ29weXJpZ2h0IChDKSAyMDA1 +LCBQb3N0Z3JlU1FMIEdsb2JhbCBEZXZlbG9wbWVudCBHcm91cA0KICoNCiAq +ICRQb3N0Z3JlU1FMJA0KICovDQojaW5jbHVkZSAicG9zdGdyZXMuaCIgDQoN +CiNpbmNsdWRlICJsb2NhbGVtYXAuaCINCg0KDQpzdGF0aWMgY2hhciAqbWF0 +Y2hfbGFuZ3VhZ2UoY2hhciAqd2lubGFuZ3VhZ2UpDQp7DQoJX2tleXZhbCAq +a3Y7DQoNCglmb3IgKGt2ID0gaXNvNjM5OyBrdi0+a2V5OyBrdisrKSB7DQoJ +CWlmICghc3RyY2FzZWNtcChrdi0+a2V5LCB3aW5sYW5ndWFnZSkpDQoJCQly +ZXR1cm4ga3YtPnZhbDsNCgl9DQoJZXJlcG9ydChFUlJPUiwNCgkJCShlcnJt +c2coImNvdWxkIG5vdCBtYXRjaCBsYW5ndWFnZSBmb3IgJXMiLCB3aW5sYW5n +dWFnZSkpKTsNCglyZXR1cm4gTlVMTDsNCn0NCg0Kc3RhdGljIGNoYXIgKm1h +dGNoX2NvdW50cnkoY2hhciAqd2luY291bnRyeSkNCnsNCglfa2V5dmFsICpr +djsNCg0KCWZvciAoa3YgPSBpc28zMTY2OyBrdi0+a2V5OyBrdisrKSB7DQoJ +CWlmICghc3RyY2FzZWNtcChrdi0+a2V5LCB3aW5jb3VudHJ5KSkNCgkJCXJl +dHVybiBrdi0+dmFsOw0KCX0NCglyZXR1cm4gTlVMTDsNCn0NCg0KLyoNCiAq +IEF0dGVtcHQgdG8gY29udmVydCBhIHdpbjMyIGxvY2FsZSAoU3dlZGlzaF9T +d2VkZW4uMTI1MikNCiAqIHRvIElDVSBmb3JtYXQgKHN2X3NlKQ0KICovDQpz +dGF0aWMgY2hhciBvdXRidWZbMTZdOw0KY2hhciAqcGd3aW4zMl9sb2NhbGVt +YXAoY2hhciAqd2lubG9jYWxlKQ0Kew0KCWNoYXIgYnVmWzI1Nl07DQoJY2hh +ciAqdW5kZXJzY29yZTsNCgljaGFyICpkb3Q7DQoJY2hhciAqY291bnRyeTsN +Cg0KCWlmIChzdHJsZW4od2lubG9jYWxlKT4yNTUpIA0KCQllcmVwb3J0KEVS +Uk9SLA0KCQkJCShlcnJtc2dfaW50ZXJuYWwoImxvY2FsZSBuYW1lIHRvbyBs +b25nIikpKTsNCglzdHJjcHkoYnVmLHdpbmxvY2FsZSk7DQoNCgl1bmRlcnNj +b3JlID0gc3RyY2hyKGJ1ZiwnXycpOw0KCWlmICghdW5kZXJzY29yZSkNCgkJ +LyogT25seSBsYW5ndWFnZSBuYW1lICovDQoJCXJldHVybiBtYXRjaF9sYW5n +dWFnZShidWYpOw0KDQoJKnVuZGVyc2NvcmUgPSAwOw0KCXVuZGVyc2NvcmUr +KzsNCg0KCWRvdCA9IHN0cmNocih1bmRlcnNjb3JlLCcuJyk7DQoJaWYgKGRv +dCkNCgkJLyogSWYgY29kZXBhZ2UgaXMgaW5jbHVkZWQsIHdlIGp1c3QgaWdu +b3JlIGl0LiAqLw0KCQkqZG90ID0gMDsNCgkNCgljb3VudHJ5ID0gbWF0Y2hf +Y291bnRyeSh1bmRlcnNjb3JlKTsNCglpZiAoIWNvdW50cnkpDQoJCXJldHVy +biBtYXRjaF9sYW5ndWFnZShidWYpOw0KDQoJc3ByaW50ZihvdXRidWYsIiVz +XyVzIixtYXRjaF9sYW5ndWFnZShidWYpLGNvdW50cnkpOw0KCXJldHVybiBv +dXRidWY7DQp9DQo= + +------_=_NextPart_001_01C5993C.1E1CB100 +Content-Type: text/plain +Content-Disposition: inline +Content-Transfer-Encoding: 8bit +MIME-Version: 1.0 + + +---------------------------(end of broadcast)--------------------------- +TIP 4: Have you searched our list archives? + + http://archives.postgresql.org + +------_=_NextPart_001_01C5993C.1E1CB100-- + +From pgsql-hackers-owner+M72011@postgresql.org Wed Aug 24 15:37:17 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j7OJbH103190 + for ; Wed, 24 Aug 2005 15:37:17 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id D5152B21F6B; + Wed, 24 Aug 2005 19:37:12 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 34C03D7357 + for ; Wed, 24 Aug 2005 15:53:55 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 85477-03 + for ; + Wed, 24 Aug 2005 18:53:52 +0000 (GMT) +Received: from rodrick.geeknet.com.au (ns1.geeknet.com.au [220.244.63.182]) + by svr1.postgresql.org (Postfix) with ESMTP id 7C774D78F9 + for ; Wed, 24 Aug 2005 15:53:48 -0300 (ADT) +Subject: Re: [HACKERS] FreeBSD ICU was Win32 unicode vs ICU +MIME-Version: 1.0 +Date: Thu, 25 Aug 2005 04:53:47 +1000 +Content-Type: text/plain; + charset="us-ascii" +Message-ID: <5066E5A966339E42AA04BA10BA706AE50A938F@rodrick.geeknet.com.au> +content-class: urn:content-classes:message +X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 +Thread-Topic: [HACKERS] FreeBSD ICU was Win32 unicode vs ICU +Thread-Index: AcWo0l6W575cyph2Twi7Fhfaa+w/tAACptMA +From: "John Hansen" +To: "Kevin McArthur" , + +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.017 required=5 tests=[AWL=0.017] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Content-Transfer-Encoding: 8bit +X-MIME-Autoconverted: from quoted-printable to 8bit by candle.pha.pa.us id j7OJbH103190 +Status: OR + +Kevin McArthur Wrote: + +> Should the postgresql project also be looking at CLDR for +> cross-platform unicode support? + +Afaict, from the ICU website, ICU too uses CLDR. +Why reinvent the wheel? + +... John + +---------------------------(end of broadcast)--------------------------- +TIP 1: if posting/reading through Usenet, please send an appropriate + subscribe-nomail command to majordomo@postgresql.org so that your + message can get through to the mailing list cleanly + +From pgsql-hackers-owner+M72581@postgresql.org Sat Sep 3 16:47:42 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j83Klg129281 + for ; Sat, 3 Sep 2005 16:47:42 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id CA484B21F00; + Sat, 3 Sep 2005 20:47:36 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 354A7D8B35 + for ; Sat, 3 Sep 2005 17:35:06 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 55971-07 + for ; + Sat, 3 Sep 2005 20:34:58 +0000 (GMT) +Received: from svana.org (svana.org [203.20.62.76]) + by svr1.postgresql.org (Postfix) with ESMTP id 4AFECD8AE7 + for ; Sat, 3 Sep 2005 17:34:56 -0300 (ADT) +Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian)) + id 1EBeim-0002xI-00; Sun, 04 Sep 2005 06:34:40 +1000 +Date: Sat, 3 Sep 2005 22:34:40 +0200 +From: Martijn van Oosterhout +To: Tom Lane +cc: Greg Stark , pgsql-hackers@postgresql.org +Subject: Locale implementation questions (was: [HACKERS] Proof of concept COLLATE support with patch) +Message-ID: <20050903203434.GA4281@svana.org> +Reply-To: Martijn van Oosterhout +References: <20050902130420.GA15466@svana.org> <87k6hzzems.fsf@stark.xeocode.com> <14696.1125675741@sss.pgh.pa.us> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha1; + protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" +Content-Disposition: inline +In-Reply-To: <14696.1125675741@sss.pgh.pa.us> +User-Agent: Mutt/1.3.28i +X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6 +X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522 48A7 6394 F08A 0DC6 7BE6 +X-PGP-Key-URL: +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.003 required=5 tests=[AWL=0.003] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + + +--mP3DRpeJDSE+ciuQ +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Fri, Sep 02, 2005 at 11:42:21AM -0400, Tom Lane wrote: +> The objection is fundamentally that a platform-specific implementation +> cannot be our long-term goal, and so expending effort on creating one +> seems like a diversion. If there were a plan put forward showing how +> this is just a useful way-station, and we could see how we'd later get +> rid of the glibc dependency without throwing away the work already done, +> then it would be a different story. + +Well, my patch showed that useful locale work can be acheived with +precisely two functions: newlocale and strxfrm_l. + +I'm going to talk about two things: one, the code from Apple. Two, how +we present locale support to users. +--- +Now, it would be really nice to take Apple's implementation in Darwin +and use that. What I don't understand is the licence of the code in +Darwin. My interpretation is that stuff in: + +http://darwinsource.opendarwin.org/10.4.2/Libc-391/locale/ + +is Apple stuff under APSL, useless to us. And that stuff in: + +http://darwinsource.opendarwin.org/10.4.2/Libc-391/locale/FreeBSD/ + +are just patches to FreeBSD and this under the normal BSD license (no +big header claiming the licence change). The good news is that the +majority of what we need is in patch form. The bad news is that the hub +of the good stuff (newlocale, duplocale, freelocale) is under a big fat +APSL licence. + +Does anyone know if this code can be used at all by BSD projects or did +they blanket relicence everything? +--- +Now, I want to bring up some points relating to including a locale +library in PostgreSQL. Given that none of the BSDs seem really +interested in fixing the issue we'll have to do it ourselves (I don't +see anyone else doing it). We can save ourselves effort by basing it on +FreeBSDs locale code, because then we can use their datafiles, which we +*definitly* don't want to maintain ourselves. Now: + +1. FreeBSDs locale list is short, some 48 compared with glibc's 217. +Hopefully Apple can expand on that in a way we can use. But given the +difference we should probably give people a way of falling back to the +system libraries in case there's a locale we don't support. + +On the other hand, lots of locales are similar so maybe people can find +ones close enough to work. No, glibc and FreeBSD use different file +formats, so you can't copy them. + +Do we want this locale data just for collation, or do we want to be +able to use it for formatting monetary amounts too? This is even more +info to store. Lots of languages use ISO/IEC 14651 for order. + +2. Locale data needs to be combined with a charset and compiled to work +with the library. PostgreSQL supports at least 15 charsets but we don't +want to ship compiled versions of all of these (Debian learnt that the +hard way). So, how do we generate the files people need. + + a. Auto-compile on demand. First time a locale is referenced spawn +the compiler to create the locale, then continue. (Ugh) + b. Add a CREATE LOCALE english AS 'en_US' WITH CHARSET 'utf8'. Then +require the COLLATE clause to refer to this identifier. This has some +appeal, seperating the system names from the PostgreSQL names. It also +gives some info regarding charsets. + c. Should users be allowed to define new locales? + d. Should admins be required to create the external files using a +program, say pg_createlocale. + +Remember, if you use a latin1 locale to sort utf8 you'll get the wrong +result, so we want to avoid that. + +3. Compiled locale files are large. One UTF-8 locale datafile can +exceed a megabyte. Do we want the option of disabling it for small +systems? + +4. Do we want the option of running system locale in parallel with the +internal ones? + +5. I think we're going to have to deal with the very real possibility +that our locale database will not be as good as some of the system +provided ones. The question is how. This is quite unlike timezones +which are quite standardized and rarely change. That database is quite +well maintained. + +Would people object to a configure option that selected: + --with-locales=3Dinternal (use pg database) + --with-locales=3Dsystem (use system database for win32, glibc or Ma= +cOS X) + --with-locales=3Dnone (what we support now, which is neither) + +I don't think it will be much of an issue to support this, all the +functions take the same parameters and have almost the same names. + +6. Locales for SQL_ASCII. Seems to me you have two options, either +reject COLLATE altogether unless they specify a charset, or don't care +and let the user shoot themselves in the foot if they wish... + +BTW, this MacOS locale supports seems to be new for 10.4.2 according to +the CVS log info, can anyone confirm this? + +Anyway, I hope this post didn't bore too much. Locale support has been +one of those things that has bugged me for a long time and it would be +nice if there could be some real movement. + +Have a nice weekend, +--=20 +Martijn van Oosterhout http://svana.org/kleptog/ +> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a +> tool for doing 5% of the work and then sitting around waiting for someone +> else to do the other 95% so you can sue them. + +--mP3DRpeJDSE+ciuQ +Content-Type: application/pgp-signature +Content-Disposition: inline + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.0.6 (GNU/Linux) +Comment: For info see http://www.gnupg.org + +iD8DBQFDGgjYIB7bNG8LQkwRAr6OAJ9uqNDKDQKWUAY4KiPAazHJ1TsVWwCeJ7sq +7hcILjdgZTQ4LjyPAhWnJwQ= +=5MT9 +-----END PGP SIGNATURE----- + +--mP3DRpeJDSE+ciuQ-- + +From pgsql-hackers-owner+M72583@postgresql.org Sat Sep 3 17:54:58 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j83Lsv108133 + for ; Sat, 3 Sep 2005 17:54:57 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id 3325AB21F00; + Sat, 3 Sep 2005 21:54:51 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id DA9AED8B14 + for ; Sat, 3 Sep 2005 18:44:52 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 88603-07 + for ; + Sat, 3 Sep 2005 21:44:51 +0000 (GMT) +Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) + by svr1.postgresql.org (Postfix) with ESMTP id 01864D8B50 + for ; Sat, 3 Sep 2005 18:44:50 -0300 (ADT) +Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) + by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) + id 1EBfog-0004U8-00; Sat, 03 Sep 2005 17:44:50 -0400 +To: Martijn van Oosterhout +cc: Tom Lane , Greg Stark , + pgsql-hackers@postgresql.org +Subject: Re: Locale implementation questions (was: [HACKERS] Proof of concept COLLATE support with patch) +References: <20050902130420.GA15466@svana.org> + <87k6hzzems.fsf@stark.xeocode.com> <14696.1125675741@sss.pgh.pa.us> + <20050903203434.GA4281@svana.org> +In-Reply-To: <20050903203434.GA4281@svana.org> +From: Greg Stark +Organization: The Emacs Conspiracy; member since 1992 +Date: 03 Sep 2005 17:44:50 -0400 +Message-ID: <87oe79ygfh.fsf@stark.xeocode.com> +Lines: 39 +User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.005 required=5 tests=[AWL=0.005] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + + +Martijn van Oosterhout writes: + +> 2. Locale data needs to be combined with a charset and compiled to work +> with the library. PostgreSQL supports at least 15 charsets but we don't +> want to ship compiled versions of all of these (Debian learnt that the +> hard way). So, how do we generate the files people need. + +That's just one of many lessons learned the hard way by distributions. Nor +will it be the last innovation in this area. + +I really find this instinct of wanting to reimplement large swaths of the OS +inside Postgres (and annoying detail-ridden swaths that are hard to get right +and continually evolving too) to be a bad idea. + +I can't believe it's harder to maintain an + +#ifdef HAVE_STRCOL_L +#else +#endif + +than it is to try to maintain an entire independent locale library. Nor is it +simpler for sysadmins to have to maintain an entirely separate set of locales +independently from the system locales. + +If you really are unhappy enough with OS setlocale implementations to want to +try to do this then it would be more helpful to do it outside of Postgres. +Package up the Apple setlocale library as a separate package that anyone can +install on Solaris, BSD, Linux or whatever. Then Postgres can just say "it +works fine with your OS library but your OS library might be very slow. Here's +a third-party library that you can install that is fast and may relieve any +problems you have with collation performance." + +But I think that's getting ahead of things. Until Postgres even supports +collations using the OS libraries you won't even know if that's even +necessary. + +-- +greg + + +---------------------------(end of broadcast)--------------------------- +TIP 4: Have you searched our list archives? + + http://archives.postgresql.org + +From pgsql-hackers-owner+M72585@postgresql.org Sun Sep 4 08:44:01 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j84Ci0127486 + for ; Sun, 4 Sep 2005 08:44:01 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id 8ED1DB21F00; + Sun, 4 Sep 2005 12:43:55 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id D87D4D6E38 + for ; Sun, 4 Sep 2005 09:31:31 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 80362-07 + for ; + Sun, 4 Sep 2005 12:31:29 +0000 (GMT) +Received: from svana.org (svana.org [203.20.62.76]) + by svr1.postgresql.org (Postfix) with ESMTP id C0F8DD6D8D + for ; Sun, 4 Sep 2005 09:31:24 -0300 (ADT) +Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian)) + id 1EBteM-0005wf-00; Sun, 04 Sep 2005 22:31:06 +1000 +Date: Sun, 4 Sep 2005 14:31:05 +0200 +From: Martijn van Oosterhout +To: Greg Stark +cc: Tom Lane , pgsql-hackers@postgresql.org +Subject: Re: Locale implementation questions (was: [HACKERS] Proof of concept COLLATE support with patch) +Message-ID: <20050904123103.GA21198@svana.org> +Reply-To: Martijn van Oosterhout +References: <20050902130420.GA15466@svana.org> <87k6hzzems.fsf@stark.xeocode.com> <14696.1125675741@sss.pgh.pa.us> <20050903203434.GA4281@svana.org> <87oe79ygfh.fsf@stark.xeocode.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha1; + protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" +Content-Disposition: inline +In-Reply-To: <87oe79ygfh.fsf@stark.xeocode.com> +User-Agent: Mutt/1.3.28i +X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6 +X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522 48A7 6394 F08A 0DC6 7BE6 +X-PGP-Key-URL: +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.003 required=5 tests=[AWL=0.003] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + + +--EeQfGwPcQSOJBaQU +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Sat, Sep 03, 2005 at 05:44:50PM -0400, Greg Stark wrote: +> [...] Nor is it +> simpler for sysadmins to have to maintain an entirely separate set of loc= +ales +> independently from the system locales. + +Indeed, I was already coming up with mechanisms to determine what +locales the system uses and try to autogenerate them. I agree though, +it's not useful for systems that already have complete locale support. +Why add to the burden? + +Anyway, my reading of the specs says that we must support the syntax. +It doesn't say we need to support any orderings other than the default +(ie what we do now). + +> If you really are unhappy enough with OS setlocale implementations to wan= +t to +> try to do this then it would be more helpful to do it outside of Postgres. +> Package up the Apple setlocale library as a separate package that anyone = +can +> install on Solaris, BSD, Linux or whatever. Then Postgres can just say "it +> works fine with your OS library but your OS library might be very slow. H= +ere's +> a third-party library that you can install that is fast and may relieve a= +ny +> problems you have with collation performance." + +That's why I asked about the patches and files that Apple wrote. What +are the licence restrictions? Would we be able to download the, what, +20 files and distribute it as a library. Being APSL we couldn't include +it in the tarball, but it could be a pgfoundry project or something. + +If somebody knows a reason why this could not be done, speak up now because +my reading of the APSL licence tells me it's fine. + +> But I think that's getting ahead of things. Until Postgres even supports +> collations using the OS libraries you won't even know if that's even +> necessary. + +Well, I added COLLATE support for ORDER BY and CREATE INDEX and it +worked in under 200 lines. I'm thinking ahead and I don't think the +COLLATE rules are that hard. Implementing them seems a bit fiddly. It +may be easiest to consider COLLATE a non-associative operator. + +I'm still unsure if I should turn the string comparison operators into +three-argument functions. + +Anyway, I'll look into the library issue first. +--=20 +Martijn van Oosterhout http://svana.org/kleptog/ +> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a +> tool for doing 5% of the work and then sitting around waiting for someone +> else to do the other 95% so you can sue them. + +--EeQfGwPcQSOJBaQU +Content-Type: application/pgp-signature +Content-Disposition: inline + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.0.6 (GNU/Linux) +Comment: For info see http://www.gnupg.org + +iD8DBQFDGukEIB7bNG8LQkwRAkeaAJ9rj5Tz7WPZpp+wWYWjTdjR68o8DwCfZzcZ +uB57noHmcnvefVoaw27bQ5Q= +=nLio +-----END PGP SIGNATURE----- + +--EeQfGwPcQSOJBaQU-- + +From pgsql-hackers-owner+M72582@postgresql.org Sat Sep 3 17:46:57 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j83Lkr106932 + for ; Sat, 3 Sep 2005 17:46:57 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id 6E192B21F00; + Sat, 3 Sep 2005 21:46:47 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 7CF09D72B7 + for ; Sat, 3 Sep 2005 18:36:14 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 77080-09 + for ; + Sat, 3 Sep 2005 21:36:13 +0000 (GMT) +Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) + by svr1.postgresql.org (Postfix) with ESMTP id 85FC0D6FEB + for ; Sat, 3 Sep 2005 18:36:09 -0300 (ADT) +Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) + by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) + id 1EBfgA-0004RS-00; Sat, 03 Sep 2005 17:36:02 -0400 +To: Tom Lane +cc: Greg Stark , Martijn van Oosterhout , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Proof of concept COLLATE support with patch +References: <20050902130420.GA15466@svana.org> + <87k6hzzems.fsf@stark.xeocode.com> <14696.1125675741@sss.pgh.pa.us> +In-Reply-To: <14696.1125675741@sss.pgh.pa.us> +From: Greg Stark +Organization: The Emacs Conspiracy; member since 1992 +Date: 03 Sep 2005 17:36:02 -0400 +Message-ID: <87u0h1ygu5.fsf@stark.xeocode.com> +Lines: 36 +User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.005 required=5 tests=[AWL=0.005] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Tom Lane writes: + +> Greg Stark writes: +> > I still doesn't get where the hostility towards this functionality comes from. +> +> We're not really willing to say "here is a piece of syntax REQUIRED +> BY THE SQL SPEC which we only support on some platforms". readline, +> O_DIRECT, and the like are a completely inappropriate analogy, because +> those are inherently platform-dependent (and not in the spec). + +But that's not the case at all. The syntax can be supported everywhere it +would just be somewhat faster on some platforms than others. It's already +reasonably fast on any platform that caches locale information which includes +glibc and presumably other free software libcs. It would be slightly faster if +there are _l functions. And much slower if the libc setlocale implementation +is braindead. But there's nothing wrong with saying "it's slow because your +libc is slow. Compile with this freely available library which has a better +implementation". The programming syntax would still be exactly 100% the same. + +> The objection is fundamentally that a platform-specific implementation +> cannot be our long-term goal, and so expending effort on creating one +> seems like a diversion. If there were a plan put forward showing how +> this is just a useful way-station, and we could see how we'd later get +> rid of the glibc dependency without throwing away the work already done, +> then it would be a different story. + +It's not like the actual calls to setlocale are going to be much code. One day +presumably some variant of these _l functions will become entirely standard. +In which case you're talking about potentially "throwing away" 50 lines of +code. The bulk of the code is going to be parsing and implementing the actual +syntax and behaviour of the SQL spec. And in any case I wouldn't expect it to +ever get thrown away. There will be people compiling on RH9 or similar vintage +systems for a long time. + +-- +greg + + +---------------------------(end of broadcast)--------------------------- +TIP 3: Have you checked our extensive FAQ? + + http://www.postgresql.org/docs/faq + +From pgsql-hackers-owner+M72589@postgresql.org Sun Sep 4 13:20:26 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j84HKQ121839 + for ; Sun, 4 Sep 2005 13:20:26 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id E4A85B21FBB; + Sun, 4 Sep 2005 17:20:23 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id C4CA7D7AEA + for ; Sun, 4 Sep 2005 14:07:02 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 63550-04 + for ; + Sun, 4 Sep 2005 17:07:01 +0000 (GMT) +Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) + by svr1.postgresql.org (Postfix) with SMTP id 02A4FD7A6F + for ; Sun, 4 Sep 2005 14:06:59 -0300 (ADT) +Received: (qmail invoked by alias); 04 Sep 2005 17:06:59 -0000 +Received: from dsl-082-083-230-040.arcor-ip.net (EHLO colt.pezone.net) [82.83.230.40] + by mail.gmx.net (mp033) with SMTP; 04 Sep 2005 19:06:59 +0200 +X-Authenticated: #495269 +From: Peter Eisentraut +To: pgsql-hackers@postgresql.org, Martijn van Oosterhout +Subject: Re: [HACKERS] Proof of concept COLLATE support with patch +Date: Sun, 4 Sep 2005 19:06:57 +0200 +User-Agent: KMail/1.8.1 +References: <20050902130420.GA15466@svana.org> +In-Reply-To: <20050902130420.GA15466@svana.org> +MIME-Version: 1.0 +Content-Type: text/plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +Content-Disposition: inline +Message-ID: <200509041906.57721.peter_e@gmx.net> +X-Y-GMX-Trusted: 0 +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.018 required=5 tests=[AWL=0.018] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Martijn van Oosterhout wrote: +> This is just a proof of concept patch. I didn't send it to -patches +> because as Tom pointed out, there's no hope of it getting in due to +> platform dependant behaviour. + +I think it would be best if we defined an internal API for plugging in +various kinds of locale support. Then you can hook in this +"newlocale", the Windows variant, ICU, or plain-old POSIX locale +support for backward compatibility. You already identified most of the +API functions. + +-- +Peter Eisentraut +http://developer.postgresql.org/~petere/ + +---------------------------(end of broadcast)--------------------------- +TIP 9: In versions below 8.0, the planner will ignore your desire to + choose an index scan if your joining column's datatypes do not + match + +From pgsql-hackers-owner+M72592@postgresql.org Sun Sep 4 18:15:47 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j84MFk103432 + for ; Sun, 4 Sep 2005 18:15:46 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id E623DB21FBF; + Sun, 4 Sep 2005 22:15:40 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id D671BD83B4 + for ; Sun, 4 Sep 2005 19:06:26 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 56030-04 + for ; + Sun, 4 Sep 2005 22:06:23 +0000 (GMT) +Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) + by svr1.postgresql.org (Postfix) with ESMTP id 44141D6F63 + for ; Sun, 4 Sep 2005 19:06:21 -0300 (ADT) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j84M6Boq008947; + Sun, 4 Sep 2005 18:06:12 -0400 (EDT) +To: Greg Stark +cc: Martijn van Oosterhout , pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Proof of concept COLLATE support with patch +In-Reply-To: <87u0h1ygu5.fsf@stark.xeocode.com> +References: <20050902130420.GA15466@svana.org> <87k6hzzems.fsf@stark.xeocode.com> <14696.1125675741@sss.pgh.pa.us> <87u0h1ygu5.fsf@stark.xeocode.com> +Comments: In-reply-to Greg Stark + message dated "03 Sep 2005 17:36:02 -0400" +Date: Sun, 04 Sep 2005 18:06:11 -0400 +Message-ID: <8946.1125871571@sss.pgh.pa.us> +From: Tom Lane +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Greg Stark writes: +> But there's nothing wrong with saying "it's slow because your +> libc is slow. Compile with this freely available library which has a better +> implementation". + +The hole in that argument is the assumption that there *is* a freely +available library that can be used (where freely == BSD license). +We wouldn't be having this discussion if we knew of one. + + regards, tom lane + +---------------------------(end of broadcast)--------------------------- +TIP 1: if posting/reading through Usenet, please send an appropriate + subscribe-nomail command to majordomo@postgresql.org so that your + message can get through to the mailing list cleanly + +From pgsql-hackers-owner+M72596@postgresql.org Sun Sep 4 19:27:26 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j84NRQ109968 + for ; Sun, 4 Sep 2005 19:27:26 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id A427211ED4E0; + Sun, 4 Sep 2005 23:27:20 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 64BFED8B2F + for ; Sun, 4 Sep 2005 20:15:22 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 08469-05 + for ; + Sun, 4 Sep 2005 23:15:21 +0000 (GMT) +Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) + by svr1.postgresql.org (Postfix) with ESMTP id CE6D9D8AD4 + for ; Sun, 4 Sep 2005 20:15:19 -0300 (ADT) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j84NFLVH009399; + Sun, 4 Sep 2005 19:15:21 -0400 (EDT) +To: Peter Eisentraut +cc: pgsql-hackers@postgresql.org, Martijn van Oosterhout +Subject: Re: [HACKERS] Proof of concept COLLATE support with patch +In-Reply-To: <200509041906.57721.peter_e@gmx.net> +References: <20050902130420.GA15466@svana.org> <200509041906.57721.peter_e@gmx.net> +Comments: In-reply-to Peter Eisentraut + message dated "Sun, 04 Sep 2005 19:06:57 +0200" +Date: Sun, 04 Sep 2005 19:15:21 -0400 +Message-ID: <9398.1125875721@sss.pgh.pa.us> +From: Tom Lane +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Peter Eisentraut writes: +> I think it would be best if we defined an internal API for plugging in +> various kinds of locale support. + +Agreed ... + +> Then you can hook in this +> "newlocale", the Windows variant, ICU, or plain-old POSIX locale +> support for backward compatibility. + +If plain old POSIX actually did what we needed, we likely wouldn't be +having this discussion at all. POSIX doesn't give us enough visibility +of the locale's properties (in particular, which character set encoding +it wants). The performance penalties it imposes are pretty bad also, +though arguably secondary. + + regards, tom lane + +---------------------------(end of broadcast)--------------------------- +TIP 1: if posting/reading through Usenet, please send an appropriate + subscribe-nomail command to majordomo@postgresql.org so that your + message can get through to the mailing list cleanly + +From pgsql-hackers-owner+M72599@postgresql.org Sun Sep 4 20:01:47 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j8501k113218 + for ; Sun, 4 Sep 2005 20:01:46 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id 5FCFD11ED4E1; + Mon, 5 Sep 2005 00:01:40 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 3CE03D8A88 + for ; Sun, 4 Sep 2005 20:53:09 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 14738-01 + for ; + Sun, 4 Sep 2005 23:53:08 +0000 (GMT) +Received: from gateway.pjmodos.bounceme.net (gprsplusa185.isp.t-mobile.cz [62.141.20.185]) + by svr1.postgresql.org (Postfix) with ESMTP id B5606D8A4E + for ; Sun, 4 Sep 2005 20:53:03 -0300 (ADT) +Received: from modos ([10.12.0.96] ident=PJMODOS) + by gateway.pjmodos.bounceme.net with esmtp (Exim 3.35 #1 (Debian)) + id 1EC4IE-0004Le-00; Mon, 05 Sep 2005 01:52:58 +0200 +Message-ID: <431B88CD.8050904@seznam.cz> +Date: Mon, 05 Sep 2005 01:52:45 +0200 +From: Petr Jelinek +User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) +X-Accept-Language: cs, en, en-us +MIME-Version: 1.0 +To: Tom Lane +cc: PostgreSQL-development +Subject: Re: [HACKERS] Proof of concept COLLATE support with patch +References: <20050902130420.GA15466@svana.org> <87k6hzzems.fsf@stark.xeocode.com> <14696.1125675741@sss.pgh.pa.us> <87u0h1ygu5.fsf@stark.xeocode.com> <8946.1125871571@sss.pgh.pa.us> +In-Reply-To: <8946.1125871571@sss.pgh.pa.us> +Content-Type: text/plain; charset=windows-1250; format=flowed +Content-Transfer-Encoding: 7bit +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=1.173 required=5 tests=[AWL=-0.253, + DNS_FROM_RFC_POST=1.376, FORGED_RCVD_HELO=0.05] +X-Spam-Level: * +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Tom Lane wrote: +> +> The hole in that argument is the assumption that there *is* a freely +> available library that can be used (where freely == BSD license). +> We wouldn't be having this discussion if we knew of one. + +I see this discussion as another reason to use ICU, I mean complete +rewrite of locale handling to use ICU on all platforms. I know it's big +project but it's doable for 8.2 and it would virtually solve all locale +problems and could be base for new unicode/locale features. I am not +sure if this is the way postgres wants to go tho (having dependency on +such a big and uncommon library). + +-- +Regards +Petr Jelinek (PJMODOS) + + +---------------------------(end of broadcast)--------------------------- +TIP 6: explain analyze is your friend + +From pgsql-hackers-owner+M72602@postgresql.org Mon Sep 5 04:02:37 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j8582Z126563 + for ; Mon, 5 Sep 2005 04:02:36 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id 6640811EB014; + Mon, 5 Sep 2005 08:02:28 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 1FC36D7841 + for ; Mon, 5 Sep 2005 04:52:11 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 09506-02 + for ; + Mon, 5 Sep 2005 07:52:06 +0000 (GMT) +Received: from svana.org (svana.org [203.20.62.76]) + by svr1.postgresql.org (Postfix) with ESMTP id 0DC42D77AE + for ; Mon, 5 Sep 2005 04:52:06 -0300 (ADT) +Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian)) + id 1ECBlg-0001TS-00; Mon, 05 Sep 2005 17:51:52 +1000 +Date: Mon, 5 Sep 2005 09:51:52 +0200 +From: Martijn van Oosterhout +To: Tom Lane +cc: Greg Stark , pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Proof of concept COLLATE support with patch +Message-ID: <20050905075152.GA5278@svana.org> +Reply-To: Martijn van Oosterhout +References: <20050902130420.GA15466@svana.org> <87k6hzzems.fsf@stark.xeocode.com> <14696.1125675741@sss.pgh.pa.us> <87u0h1ygu5.fsf@stark.xeocode.com> <8946.1125871571@sss.pgh.pa.us> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha1; + protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" +Content-Disposition: inline +In-Reply-To: <8946.1125871571@sss.pgh.pa.us> +User-Agent: Mutt/1.3.28i +X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6 +X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522 48A7 6394 F08A 0DC6 7BE6 +X-PGP-Key-URL: +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.003 required=5 tests=[AWL=0.003] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + + +--MGYHOYXEY6WxJCY8 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Sun, Sep 04, 2005 at 06:06:11PM -0400, Tom Lane wrote: +> Greg Stark writes: +> > But there's nothing wrong with saying "it's slow because your +> > libc is slow. Compile with this freely available library which has a be= +tter +> > implementation". +>=20 +> The hole in that argument is the assumption that there *is* a freely +> available library that can be used (where freely =3D=3D BSD license). +> We wouldn't be having this discussion if we knew of one. + +1. Use the one in Darwin just for the *BSDs and Solaris at least. It's +not great but it would probably work. + +2. Long term, transition to ICU (http://icu.sourceforge.net/) which is +the cross-platform internationalisation library used by Java. Looks +like Mono and Gnome/GTK are going to use this (or at least allow use +of) soon also. It uses the X licence AFAICS. It's a big pill right now +but it a year it could be installed standard on most linux systems. +It's at least avaiable everywhere now. + +Note, it's not compatable with POSIX locales so if we go there it'll be +an all or nothing switch. But if we intend to go there eventually, it +makes fiddling on our own library a waste of time. + +Incidently, I played with the code in Darwin and getting it to compile +on a system that already has extended locale support is, uh, tricky to +say the least. Lots of conflicting definitions. +--=20 +Martijn van Oosterhout http://svana.org/kleptog/ +> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a +> tool for doing 5% of the work and then sitting around waiting for someone +> else to do the other 95% so you can sue them. + +--MGYHOYXEY6WxJCY8 +Content-Type: application/pgp-signature +Content-Disposition: inline + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.0.6 (GNU/Linux) +Comment: For info see http://www.gnupg.org + +iD8DBQFDG/kXIB7bNG8LQkwRAijSAJ4xv5JiigSwEe4jgBmxvqHN+GuOgQCfSEHp +C5tpavd58A8VEnf/BBUgfzo= +=gsNf +-----END PGP SIGNATURE----- + +--MGYHOYXEY6WxJCY8-- + +From pgsql-hackers-owner+M72586@postgresql.org Sun Sep 4 09:37:44 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j84Dbh100551 + for ; Sun, 4 Sep 2005 09:37:43 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id 824CCB21F00; + Sun, 4 Sep 2005 13:37:37 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 413CCD7015 + for ; Sun, 4 Sep 2005 10:26:10 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 20529-10 + for ; + Sun, 4 Sep 2005 13:26:07 +0000 (GMT) +Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) + by svr1.postgresql.org (Postfix) with ESMTP id 12EF2D6F75 + for ; Sun, 4 Sep 2005 10:26:06 -0300 (ADT) +Received: from srascb.sra.co.jp (srascb [133.137.8.65]) + by sraigw.sra.co.jp (Postfix) with ESMTP + id 08EB262112; Sun, 4 Sep 2005 22:26:09 +0900 (JST) +Received: from srascb.sra.co.jp (localhost [127.0.0.1]) + by localhost.sra.co.jp (Postfix) with ESMTP + id D1D9610CD06; Sun, 4 Sep 2005 22:26:09 +0900 (JST) +Received: from sranhm.sra.co.jp (sranhm [133.137.44.16]) + by srascb.sra.co.jp (Postfix) with ESMTP + id ABF1210CD04; Sun, 4 Sep 2005 22:26:09 +0900 (JST) +Received: from localhost (sraihb-hub.sra.co.jp [133.137.8.6]) + by sranhm.sra.co.jp (8.9.3+3.2W/3.7W-srambox) with ESMTP id WAA12274; + Sun, 4 Sep 2005 22:26:09 +0900 +Date: Sun, 04 Sep 2005 22:25:36 +0900 (JST) +Message-ID: <20050904.222536.39155679.ishii@sraoss.co.jp> +To: kleptog@svana.org +cc: tgl@sss.pgh.pa.us, gsstark@mit.edu, pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Locale implementation questions +From: Tatsuo Ishii +In-Reply-To: <20050903203434.GA4281@svana.org> +References: <87k6hzzems.fsf@stark.xeocode.com> + <14696.1125675741@sss.pgh.pa.us> + <20050903203434.GA4281@svana.org> +X-Mailer: Mew version 2.3 on Emacs 20.7 / Mule 4.1 + =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= +MIME-Version: 1.0 +Content-Type: Text/Plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.028 required=5 tests=[AWL=0.028] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +> 3. Compiled locale files are large. One UTF-8 locale datafile can +> exceed a megabyte. Do we want the option of disabling it for small +> systems? + +To avoid the problem, you could dynmically load the compiled +tables. The charset conversion tables are handled similar way. + +Also I think it's important to allow user defined collate data. To +implement the CREATE COLLATE syntax, we need to have that capability +anyway. + +> 4. Do we want the option of running system locale in parallel with the +> internal ones? +> +> 5. I think we're going to have to deal with the very real possibility +> that our locale database will not be as good as some of the system +> provided ones. The question is how. This is quite unlike timezones +> which are quite standardized and rarely change. That database is quite +> well maintained. +> +> Would people object to a configure option that selected: +> --with-locales=internal (use pg database) +> --with-locales=system (use system database for win32, glibc or MacOS X) +> --with-locales=none (what we support now, which is neither) +> +> I don't think it will be much of an issue to support this, all the +> functions take the same parameters and have almost the same names. + +To be honest, I don't understand why we have to rely on (often broken) +system locales. I don't think building our own locale data is too +hard, and once we make up it, the maintenace cost will be very small +since it should not be changed regularly. Moreover we could enjoy the +benefit that PostgreSQL handles collations in a corret manner on any +platform which PostgreSQL supports. + +> 6. Locales for SQL_ASCII. Seems to me you have two options, either +> reject COLLATE altogether unless they specify a charset, or don't care +> and let the user shoot themselves in the foot if they wish... +> +> BTW, this MacOS locale supports seems to be new for 10.4.2 according to +> the CVS log info, can anyone confirm this? +> +> Anyway, I hope this post didn't bore too much. Locale support has been +> one of those things that has bugged me for a long time and it would be +> nice if there could be some real movement. + +Right. We Japanese (and probably Chinese too) have been bugged by the +broken mutibyte locales for long time. Using C locale help us to a +certain extent, but for Unicode we need correct locale data, othewise +the sorted data will be completely chaos. +-- +SRA OSS, Inc. Japan +Tatsuo Ishii + +---------------------------(end of broadcast)--------------------------- +TIP 1: if posting/reading through Usenet, please send an appropriate + subscribe-nomail command to majordomo@postgresql.org so that your + message can get through to the mailing list cleanly + +From pgsql-hackers-owner+M72587@postgresql.org Sun Sep 4 11:13:07 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j84FD5107053 + for ; Sun, 4 Sep 2005 11:13:06 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id D1EC5B21F00; + Sun, 4 Sep 2005 15:13:04 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 8823DD723A + for ; Sun, 4 Sep 2005 12:01:47 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 65135-01 + for ; + Sun, 4 Sep 2005 15:01:43 +0000 (GMT) +Received: from svana.org (svana.org [203.20.62.76]) + by svr1.postgresql.org (Postfix) with ESMTP id 5896DD70F7 + for ; Sun, 4 Sep 2005 12:01:40 -0300 (ADT) +Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian)) + id 1EBvzd-0006eP-00; Mon, 05 Sep 2005 01:01:13 +1000 +Date: Sun, 4 Sep 2005 17:01:13 +0200 +From: Martijn van Oosterhout +To: Tatsuo Ishii +cc: tgl@sss.pgh.pa.us, gsstark@mit.edu, pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Locale implementation questions +Message-ID: <20050904150055.GB21198@svana.org> +Reply-To: Martijn van Oosterhout +References: <87k6hzzems.fsf@stark.xeocode.com> <14696.1125675741@sss.pgh.pa.us> <20050903203434.GA4281@svana.org> <20050904.222536.39155679.ishii@sraoss.co.jp> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha1; + protocol="application/pgp-signature"; boundary="ZfOjI3PrQbgiZnxM" +Content-Disposition: inline +In-Reply-To: <20050904.222536.39155679.ishii@sraoss.co.jp> +User-Agent: Mutt/1.3.28i +X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6 +X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522 48A7 6394 F08A 0DC6 7BE6 +X-PGP-Key-URL: +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.003 required=5 tests=[AWL=0.003] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + + +--ZfOjI3PrQbgiZnxM +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Sun, Sep 04, 2005 at 10:25:36PM +0900, Tatsuo Ishii wrote: +> > 3. Compiled locale files are large. One UTF-8 locale datafile can +> > exceed a megabyte. Do we want the option of disabling it for small +> > systems? +>=20 +> To avoid the problem, you could dynmically load the compiled +> tables. The charset conversion tables are handled similar way. + +That's not the point, ofcourse they are loaded dynamically. The +question is, when do we create the files in the first place. There are +48*15 =3D 750 combinations which would amount to tens of megabytes of +essentially useless data. *When* you create the files is an important +question. Compile time is out. + +Charset conversion is completely different, there just arn't that many +combinations. + +> Also I think it's important to allow user defined collate data. To +> implement the CREATE COLLATE syntax, we need to have that capability +> anyway. + +Most OS's allow you to create collate data yourself anyway, why do we +need to implement this too? + +> To be honest, I don't understand why we have to rely on (often broken) +> system locales. I don't think building our own locale data is too +> hard, and once we make up it, the maintenace cost will be very small +> since it should not be changed regularly. Moreover we could enjoy the +> benefit that PostgreSQL handles collations in a corret manner on any +> platform which PostgreSQL supports. + +You say building our own locale data is not hard. I disagree, it's a +waste of time we can do without. Unless you know the language yourself +you cannot check changes made by anybody else. If there's an error in +locale ordering, take it up with your OS distributor. + +I also think we open ourselves to questions like: + +1. My locale is supported by the system but not by PostgreSQL, why? +2. My locale was supported last release but not this one, why? +3. Why does PostgreSQL sort differently from 'sort' or any other app on +my system? + +> Right. We Japanese (and probably Chinese too) have been bugged by the +> broken mutibyte locales for long time. Using C locale help us to a +> certain extent, but for Unicode we need correct locale data, othewise +> the sorted data will be completely chaos. + +Ok, is glibc still wrong or are they just implementing the unicode +standard and that's what's wrong. + +All I'm saying is that we need to allow use of system locales until our +native locale support is mature. In the end something like ICU +(http://icu.sourceforge.net/) will end up obsoleting us. Nobody (in +free-software anyway) uses it yet, but eventually it may be viable to +require that to allow system independant locales. +--=20 +Martijn van Oosterhout http://svana.org/kleptog/ +> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a +> tool for doing 5% of the work and then sitting around waiting for someone +> else to do the other 95% so you can sue them. + +--ZfOjI3PrQbgiZnxM +Content-Type: application/pgp-signature +Content-Disposition: inline + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.0.6 (GNU/Linux) +Comment: For info see http://www.gnupg.org + +iD8DBQFDGwwmIB7bNG8LQkwRAmKxAJ9MccMVTLVLqW7c9Lsa8FzqEMvNGgCdGFgg +nsvl/ZIAK/Qe1XpkMOItRFM= +=h0V5 +-----END PGP SIGNATURE----- + +--ZfOjI3PrQbgiZnxM-- + +From pgsql-hackers-owner+M72590@postgresql.org Sun Sep 4 15:15:31 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j84JFU107171 + for ; Sun, 4 Sep 2005 15:15:31 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id 950F5B21FBE; + Sun, 4 Sep 2005 19:15:26 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id AA4C5D85BF + for ; Sun, 4 Sep 2005 16:02:50 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 51227-06 + for ; + Sun, 4 Sep 2005 19:02:48 +0000 (GMT) +Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) + by svr1.postgresql.org (Postfix) with ESMTP id CC650D8580 + for ; Sun, 4 Sep 2005 16:02:46 -0300 (ADT) +Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) + by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) + id 1EBzlN-0003LY-00; Sun, 04 Sep 2005 15:02:45 -0400 +To: Tatsuo Ishii +cc: kleptog@svana.org, tgl@sss.pgh.pa.us, gsstark@mit.edu, + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Locale implementation questions +References: <87k6hzzems.fsf@stark.xeocode.com> + <14696.1125675741@sss.pgh.pa.us> <20050903203434.GA4281@svana.org> + <20050904.222536.39155679.ishii@sraoss.co.jp> +In-Reply-To: <20050904.222536.39155679.ishii@sraoss.co.jp> +From: Greg Stark +Organization: The Emacs Conspiracy; member since 1992 +Date: 04 Sep 2005 15:02:45 -0400 +Message-ID: <87fysky7u2.fsf@stark.xeocode.com> +Lines: 22 +User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.005 required=5 tests=[AWL=0.005] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + + +Tatsuo Ishii writes: + +> To be honest, I don't understand why we have to rely on (often broken) +> system locales. I don't think building our own locale data is too +> hard, and once we make up it, the maintenace cost will be very small +> since it should not be changed regularly. Moreover we could enjoy the +> benefit that PostgreSQL handles collations in a corret manner on any +> platform which PostgreSQL supports. + +I think it's sheer madness to try to reproduce large swaths of the OS inside +Postgres because you're unhappy with the quality of the OS implementation. You +should be asking yourself why OS vendors have such a hard time getting this +stuff right and why would Postgres do any better. Wouldn't that work be better +spent improving the database functionality of Postgres? + +Or at least better spent improving the locale support for the entire OS? It +would be positively awful if every application on my system had its own locale +database each of which had its own set of bugs and its own feature set. + +-- +greg + + +---------------------------(end of broadcast)--------------------------- +TIP 3: Have you checked our extensive FAQ? + + http://www.postgresql.org/docs/faq + +From pgsql-hackers-owner+M72597@postgresql.org Sun Sep 4 19:28:34 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j84NSY110074 + for ; Sun, 4 Sep 2005 19:28:34 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id 7898611ED4E0; + Sun, 4 Sep 2005 23:28:28 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id BE640D8910 + for ; Sun, 4 Sep 2005 20:19:37 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 09430-04 + for ; + Sun, 4 Sep 2005 23:19:37 +0000 (GMT) +Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) + by svr1.postgresql.org (Postfix) with ESMTP id 7DE22D8864 + for ; Sun, 4 Sep 2005 20:19:34 -0300 (ADT) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j84NJclc009441; + Sun, 4 Sep 2005 19:19:38 -0400 (EDT) +To: Greg Stark +cc: Tatsuo Ishii , kleptog@svana.org, + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Locale implementation questions +In-Reply-To: <87fysky7u2.fsf@stark.xeocode.com> +References: <87k6hzzems.fsf@stark.xeocode.com> <14696.1125675741@sss.pgh.pa.us> <20050903203434.GA4281@svana.org> <20050904.222536.39155679.ishii@sraoss.co.jp> <87fysky7u2.fsf@stark.xeocode.com> +Comments: In-reply-to Greg Stark + message dated "04 Sep 2005 15:02:45 -0400" +Date: Sun, 04 Sep 2005 19:19:38 -0400 +Message-ID: <9440.1125875978@sss.pgh.pa.us> +From: Tom Lane +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Greg Stark writes: +> I think it's sheer madness to try to reproduce large swaths of the OS +> inside Postgres because you're unhappy with the quality of the OS +> implementation. You should be asking yourself why OS vendors have such +> a hard time getting this stuff right + +In the case of the *BSDs, it's pretty obviously because they don't care. + +> and why would Postgres do any better + +In the first place, we do care, and in the second place, having to deal +with only one set of locale bugs would in itself be a huge advance over +where we are now. + +We went over to maintaining our own timezone code for more or less the +same reasons, and in hindsight that was obviously the right decision. +Locale support is a bigger chunk, no doubt about it, but we also have +a lot of motivation. + + regards, tom lane + +---------------------------(end of broadcast)--------------------------- +TIP 2: Don't 'kill -9' the postmaster + +From pgsql-hackers-owner+M72619@postgresql.org Mon Sep 5 18:14:28 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j85MER115087 + for ; Mon, 5 Sep 2005 18:14:27 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id 68D9F11EB015; + Mon, 5 Sep 2005 22:14:19 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 92268D6FB8 + for ; Mon, 5 Sep 2005 18:59:42 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 29325-07 + for ; + Mon, 5 Sep 2005 21:59:38 +0000 (GMT) +Received: from svana.org (svana.org [203.20.62.76]) + by svr1.postgresql.org (Postfix) with ESMTP id 98C2CD7A97 + for ; Mon, 5 Sep 2005 18:59:33 -0300 (ADT) +Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian)) + id 1ECP02-0004SQ-00; Tue, 06 Sep 2005 07:59:34 +1000 +Date: Mon, 5 Sep 2005 23:59:33 +0200 +From: Martijn van Oosterhout +To: pgsql-hackers@postgresql.org +Subject: [HACKERS] Install Darwin's locale library on your system :) +Message-ID: <20050905215928.GB5278@svana.org> +Reply-To: Martijn van Oosterhout +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha1; + protocol="application/pgp-signature"; boundary="hHWLQfXTYDoKhP50" +Content-Disposition: inline +User-Agent: Mutt/1.3.28i +X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6 +X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522 48A7 6394 F08A 0DC6 7BE6 +X-PGP-Key-URL: +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.003 required=5 tests=[AWL=0.003] +X-Mailing-List: pgsql-hackers +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + + +--hHWLQfXTYDoKhP50 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +Well, it was pointed out the other day that the Darwin C library +supports the non-standard extensions to the POSIX locale interface and +that this might be ported to other systems so PostgreSQL could use it. + +So, I have written a few scripts which download the libc and locale +library from darwinsource, shuffle some files around and build the +result into a library called libdummylocale.so. It basically completely +replaces your locale support on whatever system you use it on. + +It's all under the APSL, though some parts may be BSD licenced. + +Let me say right now, the locale support here sucks, no two ways about +it. It doesn't support a single UTF-8 locale. Oh, it lets you specify +them, but when you ask for the CHARSET it still says US-ASCII. It does +support a number of other different charsets. (Not for collation +though). + +So my challenge to those people who think maintaining a locale library +is easy: make *one* locale in FreeBSD (or Darwin or this lib) support +full UTF-8 collation in whatever locale and/or charset you choose. It's +all downhill from there. + +While it builds simple programs, I don't think it's totally safe. You'd +need to rename the headers at least. And building on Darwin will +probably blow up due to the way it plays fast and loose with Darwin +specific #defines. But it's a beginning if anyone is interested. It +builds in my glibc system. + +I'm going to drop the idea of making a locale library, there's just +nothing good enough. glibc is the only thing that comes close. From here +on I'm going to work on COLLATE for systems that support xlocale, with +an eye on ICU if/when it becomes standard enough. + +Download: http://svana.org/kleptog/pgsql/dummylocale.tar.gz + +Have a nice day, +--=20 +Martijn van Oosterhout http://svana.org/kleptog/ +> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a +> tool for doing 5% of the work and then sitting around waiting for someone +> else to do the other 95% so you can sue them. + +--hHWLQfXTYDoKhP50 +Content-Type: application/pgp-signature +Content-Disposition: inline + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.0.6 (GNU/Linux) +Comment: For info see http://www.gnupg.org + +iD8DBQFDHL++IB7bNG8LQkwRAjvyAJ98Hwm6Ak7zSdEU7shrzxbvMJJp/QCfcJSq +ZseeCwJGWAs+3MEPEr8u2dM= +=rr4R +-----END PGP SIGNATURE----- + +--hHWLQfXTYDoKhP50-- + +From pgsql-patches-owner+M17366@postgresql.org Wed Sep 7 12:16:02 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j87GG1104073 + for ; Wed, 7 Sep 2005 12:16:01 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id D3FD711EB015; + Wed, 7 Sep 2005 16:15:58 +0000 (GMT) +X-Original-To: pgsql-patches-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 326F8D7B55 + for ; Wed, 7 Sep 2005 13:11:41 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 66946-04 + for ; + Wed, 7 Sep 2005 16:11:25 +0000 (GMT) +Received: from svana.org (svana.org [203.20.62.76]) + by svr1.postgresql.org (Postfix) with ESMTP id D88A6D6E3B + for ; Wed, 7 Sep 2005 13:11:20 -0300 (ADT) +Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian)) + id 1ED2W5-00052g-00; Thu, 08 Sep 2005 02:11:17 +1000 +Date: Wed, 7 Sep 2005 18:11:17 +0200 +From: Martijn van Oosterhout +To: pgsql-patches@postgresql.org +Subject: [PATCHES] For review: Initial support for COLLATE +Message-ID: <20050907161112.GA10273@svana.org> +Reply-To: Martijn van Oosterhout +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha1; + protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" +Content-Disposition: inline +User-Agent: Mutt/1.3.28i +X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6 +X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522 48A7 6394 F08A 0DC6 7BE6 +X-PGP-Key-URL: +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.003 required=5 tests=[AWL=0.003] +X-Mailing-List: pgsql-patches +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-patches-owner@postgresql.org +Status: OR + + +--ibTvN161/egqYuK8 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +[Please CC any replies, thanks] + +This patch is the beginnings of support for COLLATE. I need to do some +other work for a few days so I'm posting here to get some initial +reviews. Various parts are marked [done] and [not done]. + +The steps involved are: + +- Add COLLATE to grammer as part of expression tree. New CollateClause + node stores the relevent facts. [done] + +- parse_expr goes through tree and determines the appropriate COLLATE + state for each node as per SQL spec. [done] + + Note: PostgreSQL doesn't really have a way to identify text-like + types and there's no real need to anyway. The implementation allows + any node to have a collate state. This can be used for other things, + see below. + +- CREATE COLLATE statement [not done, currently added on the fly] + +- Two new datatypes, pg_locale_t and pg_localedata_t. The former + represents a locale (and will eventually have an OID). The latter is + an anonymous cookie that stores locale specific information and is + passed to functions that need it. It may be that once done, this + latter type will vanish again. [done] + +- Several utility functions in the new file pg_xlocale.c for use by the + rest of the system. [done] + +- Add boolean column 'proislocalized' to pg_proc which indicates if the + output of this function is affected by the LOCALE. eg textcat doesn't + care but textle does. [done] This is for: + + a) So the parser can complain about functions that look at the + locale/collate order but it's not clear from the arguments (state + None per SQL spec) and it's not specified explicitly. [not done] + + b) So when a column or function is indexed, the index code knows if + the locale is relevent to sorting order. This is particularly + interesting for btree indexes on character strings. [not done] + + Currently I've marked 58 functions as being locale sensetive, but + that list will need careful going over. To some extent it can be + checked automatically by examining which backend functions use the + new PG_GETLOCALE() macro. + +- Check for correct encoding in loaded locales [not done] + +- Check the partial indexes do the right thing when matching + expressions. [not done] + +- Docs, regression, etc... + +- make check: right now I'm getting some regressions in the rules + and plpgsql, very odd... Possibly due to the fact that rules get + collate nodes with locales that don't persist across invokations. + +Goals: + +- This setup extends the SQL spec a bit, in the sense that COLLATE can + be attached to anything. It is my intention to allow functions such + as to_char() and to_timestamp() to be localized. eg: + +test=3D# select cash_out('1.00'::money collate 'nl_NL'), cash_out('1.00'::m= +oney collate 'en_AU'); + cash_out | cash_out=20 +----------+---------- + EUR1,00 | $1.00 +(1 row) + +- Should LOCALE be created as a synonym for COLLATE? It reads more + naturally. + +- Currently LC_COLLATE is fixed at initdb and LC_NUMERIC and + LC_CURRENCY can be altered. The idea is that eventually even + LC_COLLATE can be altered anytime (from the users point view anyway), + as any objects that care will store the collate order they want and + can execute functions as appropriate. + +- Eventually once the transition to full locale support is complete, + change the backend so it always runs under locale C and only + functions on userdata are affected by locales. This means that + unquoted identifiers when converted to lowercase will be lowered as + per ASCII rules. Judging by [1] this is what people want, but + feedback would be nice. + +[1] http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg39742.html + + Hence, right now, names compare using normal strcmp, but text, + varchar, etc use strcoll. + +- The patch as it currently stands won't compile at all without system + xlocale support. The goal is to provide some level of backward + compatability where the COLLATE clause can be used, but only to + affect functions like to_char(). Changing COLLATE order would be + forbidden (ie just like now). + +- Eventually, once the parts relevent to locales are sufficiently + abstracted, look into ICU to plug it in. Unfortunatly, it's a + completely different model (all utf-16) so that's another phase + altogether. + +- The default type output functions should never be locale specific. + This is to avoid issues with pgdump and frontends. Create a function + 'localize(anyelement)' to "do the obvious" to force it to happen. + +Download:=20 + Compressed 57K, uncompressed >500K but that's due to rewriting the + whole of pg_proc. The important code is not so big. Against todays + CVS. + +http://svana.org/kleptog/pgsql/collate2.patch.gz + +Examples: + +test=3D# SELECT text('a') < text('B') COLLATE 'C', text('a') < text('B') CO= +LLATE 'en_US.UTF-8'; + ?column? | ?column?=20 +----------+---------- + f | t +(1 row) + +test=3D# SELECT text('A') < text('b') COLLATE 'C', text('A') < text('b') CO= +LLATE 'en_US.UTF-8'; + ?column? | ?column?=20 +----------+---------- + t | t +(1 row) + +test=3D# SELECT text('A') COLLATE 'en_US.UTF-8' < text('b') COLLATE 'C'; +ERROR: Conflicting COLLATE clauses + +Have a nice day, +--=20 +Martijn van Oosterhout http://svana.org/kleptog/ +> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a +> tool for doing 5% of the work and then sitting around waiting for someone +> else to do the other 95% so you can sue them. + +--ibTvN161/egqYuK8 +Content-Type: application/pgp-signature +Content-Disposition: inline + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.0.6 (GNU/Linux) +Comment: For info see http://www.gnupg.org + +iD8DBQFDHxEgIB7bNG8LQkwRAqTqAJ0TOH3RkxnYHJmCPhjjYha0idsEoACfTjY0 +EP4a7CtIaZ0Ar0dyuPja3h8= +=8zan +-----END PGP SIGNATURE----- + +--ibTvN161/egqYuK8-- + +From pgsql-patches-owner+M17368@postgresql.org Wed Sep 7 16:31:39 2005 +Return-path: +Received: from ams.hub.org (ams.hub.org [200.46.204.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j87KVd101436 + for ; Wed, 7 Sep 2005 16:31:39 -0400 (EDT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by ams.hub.org (Postfix) with ESMTP id 847AF11EB01E; + Wed, 7 Sep 2005 20:31:32 +0000 (GMT) +X-Original-To: pgsql-patches-postgresql.org@localhost.postgresql.org +Received: from localhost (av.hub.org [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 22823D7D5C + for ; Wed, 7 Sep 2005 16:12:20 -0300 (ADT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 19251-09 + for ; + Wed, 7 Sep 2005 19:12:13 +0000 (GMT) +Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) + by svr1.postgresql.org (Postfix) with SMTP id 05BA7D7B7E + for ; Wed, 7 Sep 2005 16:12:13 -0300 (ADT) +Received: (qmail invoked by alias); 07 Sep 2005 19:12:14 -0000 +Received: from dsl-082-083-195-234.arcor-ip.net (EHLO colt.pezone.net) [82.83.195.234] + by mail.gmx.net (mp022) with SMTP; 07 Sep 2005 21:12:14 +0200 +X-Authenticated: #495269 +From: Peter Eisentraut +To: Martijn van Oosterhout +Subject: Re: [PATCHES] For review: Initial support for COLLATE +Date: Wed, 7 Sep 2005 21:12:12 +0200 +User-Agent: KMail/1.8.1 +References: <20050907161112.GA10273@svana.org> +In-Reply-To: <20050907161112.GA10273@svana.org> +cc: pgsql-patches@postgresql.org +MIME-Version: 1.0 +Content-Type: text/plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +Content-Disposition: inline +Message-ID: <200509072112.12955.peter_e@gmx.net> +X-Y-GMX-Trusted: 0 +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Status: No, hits=0.044 required=5 tests=[AWL=-0.006, + FORGED_RCVD_HELO=0.05] +X-Mailing-List: pgsql-patches +List-Archive: +List-Help: +List-Id: +List-Owner: +List-Post: +List-Subscribe: +List-Unsubscribe: +Precedence: bulk +Sender: pgsql-patches-owner@postgresql.org +Status: OR + +Martijn van Oosterhout wrote: +> - Should LOCALE be created as a synonym for COLLATE? It reads more +> naturally. + +No, and in fact the terminology mixup in your patch and description +concerns me. If you are talking about collation, then the data types, +system catalog columns, etc. should talk about collation, not about +"locale", because that encompasses a number of other things that can be +handled independent of the collation order. + +-- +Peter Eisentraut +http://developer.postgresql.org/~petere/ + +---------------------------(end of broadcast)--------------------------- +TIP 9: In versions below 8.0, the planner will ignore your desire to + choose an index scan if your joining column's datatypes do not + match +