Re: UTF-8 support in DBD::mysql
am 24.02.2006 18:54:18 von Jan Kratochvil
--qlTNgmc+xy1dBmNv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi,
On Fri, 24 Feb 2006 18:02:27 +0100, Dominic Mitchell wrote:
....
> Ideally, I'm looking for something like PostgreSQL's pg_enable_utf8
> flag: http://search.cpan.org/~dbdpg/DBD-Pg-1.44/Pg.pm#pg_enable_ut f8
It looks also as a hack. It should properly retrieve the charset of the
retrieved column but currently DBD::mysql does not parse it enough to be able
to mark it appropriately.
In fact I gave up and rather mark it utf-8 by hand from Perl when appropriate.
Regards,
Lace
--qlTNgmc+xy1dBmNv
Content-Type: message/rfc822
Content-Disposition: inline
Return-Path:
Received: from lists.mysql.com (lists2.mysql.com [213.136.52.31])
by pauline.vellum.cz (8.11.6/8.11.6) with SMTP id j5PCGOJ04886
for ; Sat, 25 Jun 2005 14:16:24 +0200
Received: (qmail 23636 invoked by uid 510); 25 Jun 2005 12:16:12 -0000
Mailing-List: contact perl-help@lists.mysql.com; run by ezmlm
List-ID:
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Archive: http://lists.mysql.com/perl/3563
Delivered-To: mailing list perl@lists.mysql.com
Received: (qmail 23614 invoked by uid 509); 25 Jun 2005 12:16:12 -0000
Received-SPF: neutral (listsnew.mysql.com: local policy)
Date: Sat, 25 Jun 2005 21:16:16 +0900
From: Jan Kratochvil
To: perl@lists.mysql.com
Subject: [patch] DBD::mysql UTF-8 handling
Message-ID: <20050625121615.GA8358@kashome.dyn.jankratochvil.net>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi,
yet another mail in the utf8 saga.
Attached patch is just a followup to:
http://lists.mysql.com/perl/3006?f=plain
but also implementing proper _writing_ of utf-8 data to MySQL. The patch above
worked fine for me for _reading_ but I was unable to find out any way how to
write them properly in utf-8.
Be aware you need to use for tests (%ENV{LC_*/LANG} are not enough):
mysql --default-character-set=utf8 ...
Tests are not written for this patch.
Regards,
Lace
--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="DBD-mysql-2.9008-lace_utf8_0.patch"
diff -ru DBD-mysql-2.9008-orig/dbdimp.c DBD-mysql-2.9008/dbdimp.c
--- DBD-mysql-2.9008-orig/dbdimp.c 2005-05-25 07:11:08.000000000 +0200
+++ DBD-mysql-2.9008/dbdimp.c 2005-06-25 13:34:25.000000000 +0200
@@ -934,6 +934,15 @@
client_flag &= ~CLIENT_FOUND_ROWS;
}
}
+ if ((svp = hv_fetch(hv, "mysql_enable_utf8", 17,
+ FALSE)) && *svp) {
+ /* Do not: imp_dbh->enable_utf8 ?
+ * as we are called earlier than it is set
+ * and mysql_options() must be before: mysql_real_connect()
+ */
+ mysql_options(sock, MYSQL_SET_CHARSET_NAME,
+ (SvTRUE(*svp) ? "utf8" : "latin1"));
+ }
#if defined(DBD_MYSQL_WITH_SSL) && \
(defined(CLIENT_SSL) || (MYSQL_VERSION_ID >= 40000))
if ((svp = hv_fetch(hv, "mysql_ssl", 9, FALSE)) && *svp) {
@@ -1119,6 +1128,9 @@
imp_dbh->has_transactions = TRUE;
imp_dbh->auto_reconnect = FALSE; /* Safer we flip this to TRUE perl side
if we detect a mod_perl env. */
+#ifdef is_utf8_string
+ imp_dbh->enable_utf8 = FALSE; /* initialize mysql_enable_utf8 */
+#endif
if (!_MyLogin(imp_dbh)) {
do_error(dbh, mysql_errno(&imp_dbh->mysql),
@@ -1399,6 +1411,10 @@
}
else if (key_len == 31 && strEQ(key,"mysql_unsafe_bind_type_guessing") )
imp_dbh->bind_type_guessing = SvIV(valuesv);
+#ifdef is_utf8_string
+ else if (strEQ(key, "mysql_enable_utf8"))
+ imp_dbh->enable_utf8 = bool_value;
+#endif
else
return FALSE;
@@ -1483,6 +1499,8 @@
/* Obsolete, as of 2.09! */
const char* msg = mysql_error(&imp_dbh->mysql);
result = sv_2mortal(newSVpv(msg, strlen(msg)));
+ } else if (strEQ(key, "enable_utf8")) {
+ result = sv_2mortal(newSViv(imp_dbh->enable_utf8));
}
break;
case 'd':
@@ -1843,6 +1861,12 @@
*
************************************************************ **************/
+int is_high_bit_set(char *val) {
+ while (*val++)
+ if (*val & 0x80) return 1;
+ return 0;
+}
+
AV* dbd_st_fetch(SV* sth, imp_sth_t* imp_sth) {
int num_fields;
int ChopBlanks;
@@ -1893,6 +1917,12 @@
}
sv_setpvn(sv, col, len);
+
+#ifdef is_utf8_string
+ if (imp_dbh->enable_utf8 &&
+ is_high_bit_set(col) && is_utf8_string(col, len))
+ SvUTF8_on(sv);
+#endif
} else {
(void) SvOK_off(sv); /* Field is NULL, return undef */
}
diff -ru DBD-mysql-2.9008-orig/dbdimp.h DBD-mysql-2.9008/dbdimp.h
--- DBD-mysql-2.9008-orig/dbdimp.h 2005-04-13 04:22:41.000000000 +0200
+++ DBD-mysql-2.9008/dbdimp.h 2005-06-25 11:26:37.000000000 +0200
@@ -115,6 +115,9 @@
unsigned int auto_reconnects_failed;
} stats;
unsigned short int bind_type_guessing;
+#ifdef is_utf8_string
+ bool enable_utf8; /* should we attempt to make utf8 strings? */
+#endif
};
diff -ru DBD-mysql-2.9008-orig/lib/DBD/mysql.pm DBD-mysql-2.9008/lib/DBD/mysql.pm
--- DBD-mysql-2.9008-orig/lib/DBD/mysql.pm 2005-06-06 02:57:25.000000000 +0200
+++ DBD-mysql-2.9008/lib/DBD/mysql.pm 2005-06-25 11:26:01.000000000 +0200
@@ -879,6 +879,18 @@
AutoCommit is turned off, and when AutoCommit is turned off, DBD::mysql will
not automatically reconnect to the server.
+=item mysql_enable_utf8
+
+This attribute determines whether DBD::mysql should assume strings stored
+in the database are utf8. This feature defaults to off. When set, and if
+a retrieved string validates as utf8, then the magic flag on the string
+is turned on, making perl use character semantics on it. You need to
+turn this on if you store your data as utf8; otherwise you may notice
+that although data is displayed correctly when retrieved, length()
+returns results that are too large.
+
+This option is experimental and may change in future versions.
+
=head1 STATEMENT HANDLES
The statement handles of DBD::mysql support a number
--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=lace@jankratochvil.net
--C7zPtVaVf+AK4Oqc--
--qlTNgmc+xy1dBmNv
Content-Type: message/rfc822
Content-Disposition: inline
Return-Path:
Received: from lists.mysql.com (lists2.mysql.com [213.136.52.31])
by pauline.vellum.cz (8.11.6/8.11.6) with SMTP id j5PFW9J08199
for ; Sat, 25 Jun 2005 17:32:09 +0200
Received: (qmail 25890 invoked by uid 510); 25 Jun 2005 15:31:57 -0000
Mailing-List: contact perl-help@lists.mysql.com; run by ezmlm
List-ID:
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Archive: http://lists.mysql.com/perl/3564
Delivered-To: mailing list perl@lists.mysql.com
Received: (qmail 25868 invoked by uid 509); 25 Jun 2005 15:31:57 -0000
Received-SPF: pass (listsnew.mysql.com: local policy)
Date: Sat, 25 Jun 2005 11:27:38 -0400 (EDT)
From: Rudy Lippan
X-X-Sender: rlippan@elfride.ineffable.net
To: Jan Kratochvil
cc: perl@lists.mysql.com
Subject: Re: [patch] DBD::mysql UTF-8 handling
In-Reply-To: <20050625121615.GA8358@kashome.dyn.jankratochvil.net>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID:
Content-Disposition: INLINE
On Sat, 25 Jun 2005, Jan Kratochvil wrote:
> yet another mail in the utf8 saga.
>
> Attached patch is just a followup to:
> http://lists.mysql.com/perl/3006?f=plain
>
> but also implementing proper _writing_ of utf-8 data to MySQL. The patch above
> worked fine for me for _reading_ but I was unable to find out any way how to
> write them properly in utf-8.
>
But the patches don't make a distinction of binary vs. char types, ie. only
char/varchar/text/&c. should be flagged as utf-8 whereas BLOBs and friends
should be left alone, right? Or did I miss the code that does that, for I only
did a cursory look over?
-r
--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=lace@jankratochvil.net
--qlTNgmc+xy1dBmNv
Content-Type: message/rfc822
Content-Disposition: inline
Return-Path:
Received: from lists.mysql.com (lists2.mysql.com [213.136.52.31])
by pauline.vellum.cz (8.11.6/8.11.6) with SMTP id j5PJH9J04794
for ; Sat, 25 Jun 2005 21:17:09 +0200
Received: (qmail 27474 invoked by uid 510); 25 Jun 2005 19:16:57 -0000
Mailing-List: contact perl-help@lists.mysql.com; run by ezmlm
List-ID:
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Archive: http://lists.mysql.com/perl/3565
Delivered-To: mailing list perl@lists.mysql.com
Received: (qmail 27451 invoked by uid 509); 25 Jun 2005 19:16:56 -0000
Received-SPF: neutral (listsnew.mysql.com: local policy)
Date: Sun, 26 Jun 2005 04:16:59 +0900
From: Jan Kratochvil
To: Rudy Lippan
Cc: perl@lists.mysql.com
Subject: Re: [patch] DBD::mysql UTF-8 handling
Message-ID: <20050625191659.GA15536@kashome.dyn.jankratochvil.net>
References: <20050625121615.GA8358@kashome.dyn.jankratochvil.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.4.2.1i
Hi,
On Sun, 26 Jun 2005 00:27:38 +0900, Rudy Lippan wrote:
> On Sat, 25 Jun 2005, Jan Kratochvil wrote:
....
> > Attached patch is just a followup to:
> > http://lists.mysql.com/perl/3006?f=plain
....
> But the patches don't make a distinction of binary vs. char types, ie. only
> char/varchar/text/&c. should be flagged as utf-8
You are right. It was already noted in the thread round the referenced original
mail. I just needed to get it working. Fast. In 99% of cases this hack should
work as all the binary data should get filtered there by is_utf8_string()
(on _read_, on _write_ this patch should be right).
This is not for any final import but it still better hack than the one before.
Regards,
Lace
--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=lace@jankratochvil.net
--qlTNgmc+xy1dBmNv
Content-Type: text/plain; charset=us-ascii
--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org
--qlTNgmc+xy1dBmNv--
Re: UTF-8 support in DBD::mysql
am 25.02.2006 11:33:08 von Dominic Mitchell
Jan Kratochvil said:
> On Fri, 24 Feb 2006 18:02:27 +0100, Dominic Mitchell wrote:
>> Ideally, I'm looking for something like PostgreSQL's pg_enable_utf8
>> flag: http://search.cpan.org/~dbdpg/DBD-Pg-1.44/Pg.pm#pg_enable_ut f8
>
> It looks also as a hack. It should properly retrieve the charset of the
> retrieved column but currently DBD::mysql does not parse it enough to be
> able to mark it appropriately.
It is a hack, but it's a useful one. General charset support is not
needed. It's only UTF-8 support that needs special handling by Perl.
You could get into long details about the correct API for transcoding
automatically into the desired charset from whatever charset the database
has stored your data in. But it smacks of overengineering, and not making
the common case simple.
UTF-8 support in Perl is a special case amongst all charsets, so I feel
it's worth adding a little bit of help for it. You wouldn't have to /use/
the proposed hack. But it's there for people like me who do need it.
> In fact I gave up and rather mark it utf-8 by hand from Perl when
appropriate.
That's exactly what I *don't* want to be doing. I gave it UTF-8 -- it
should be able to give me UTF-8 back.
-Dom
--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org
Re: UTF-8 support in DBD::mysql
am 25.02.2006 12:06:18 von Jan Kratochvil
Hi,
On Sat, 25 Feb 2006 11:33:08 +0100, Dominic Mitchell wrote:
....
> It is a hack, but it's a useful one.
....
> You could get into long details about the correct API for transcoding
> automatically into the desired charset from whatever charset the database
> has stored your data in. But it smacks of overengineering, and not making
> the common case simple.
I was checking now that utf-8 looks really complicated enough to not to be
fooled by random data as "false positive". I can report that my engine was
getting MMSE (MMS Encapsulation - mobile phones binary format) data marked
as utf-8 (and therefore failing binary decoding of bytes-oriented MMSE).
Maybe I did there some other mistake or that previously attached patch of mine
is broken (still does not look so to me). Still the hassle around and
unpredictable behavior on possibly random failing service for the clients
prevented me from using it for real.
....
> > In fact I gave up and rather mark it utf-8 by hand from Perl when
> > appropriate.
>
> That's exactly what I *don't* want to be doing. I gave it UTF-8 -- it
> should be able to give me UTF-8 back.
You gave it utf-8 marker when it was really utf-8. It should give back utf-8
marker when it is really utf-8.
Regards,
Lace
--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org
Re: UTF-8 support in DBD::mysql
am 25.02.2006 20:13:00 von Dominic Mitchell
Jan Kratochvil said:
> Hi,
>
> On Sat, 25 Feb 2006 11:33:08 +0100, Dominic Mitchell wrote:
> ...
>> It is a hack, but it's a useful one.
> ...
>> You could get into long details about the correct API for transcoding
>> automatically into the desired charset from whatever charset the
>> database
>> has stored your data in. But it smacks of overengineering, and not
>> making
>> the common case simple.
>
> I was checking now that utf-8 looks really complicated enough to not to be
> fooled by random data as "false positive". I can report that my engine was
> getting MMSE (MMS Encapsulation - mobile phones binary format) data marked
> as utf-8 (and therefore failing binary decoding of bytes-oriented MMSE).
Well, UTF-8 is designed so that the longer the string, the smaller chance
of something which is not UTF-8 being identified as UTF-8. The wikipedia
article explains this better.
http://en.wikipedia.org/wiki/UTF-8#Advantages_and_disadvanta ges
Also, are you talking about data going into MySQL? I'm not actually
concerned about that, only about retrieveing it on the way out.
> Maybe I did there some other mistake or that previously attached patch of
> mine
> is broken (still does not look so to me). Still the hassle around and
> unpredictable behavior on possibly random failing service for the clients
> prevented me from using it for real.
Well, it behaviour should be hidden behind a flag, so it can be turned off
if needed. I'm not proposing that it's enabled by default.
> ...
>> > In fact I gave up and rather mark it utf-8 by hand from Perl when
>> > appropriate.
>>
>> That's exactly what I *don't* want to be doing. I gave it UTF-8 -- it
>> should be able to give me UTF-8 back.
>
> You gave it utf-8 marker when it was really utf-8. It should give back
> utf-8
> marker when it is really utf-8.
I think that's what I'm proposing. :-)
-Dom
--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org
[PATCH] Re: UTF-8 support in DBD::mysql
am 07.03.2006 15:02:46 von Dominic Mitchell
--------------010107060505040007010203
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Dominic Mitchell wrote:
> Are there any plans to introduce UTF-8 support to DBD::mysql? At the
> moment, when I retrieve UTF-8 data from MySQL, it doesn't have the UTF-8
> flag set on the returned string. This means that I have to litter my
> code with calls to Encode::decode_utf8().
>
> Ideally, I'm looking for something like PostgreSQL's pg_enable_utf8
> flag: http://search.cpan.org/~dbdpg/DBD-Pg-1.44/Pg.pm#pg_enable_ut f8
>
> If it's agreed that the functionality is desired, I'm happy to create a
> patch based on the PostgreSQL support.
Ok, this is a reworking of the previous UTF-8 patch, with the following
features:
* Only turned on if defined(sv_decode_utf8) && MYSQL_VERSION_ID >=
SERVER_PREPARE_VERSION.
The first requirement is so that the functions are actually available
in Perl. The second is because there doesn't appear to be any column
type information available in the older branch of dbd_st_fetch. If
somebody could point out how to do that, I would be most appreciative.
* The patch includes a way to retrieve the value of the flag as well as
set it. :-)
* This patch includes the fix for quote() that I posted last week.
* I've included a test to ensure that we can get UTF-8 out of the
database again.
This is all patched against DBD::mysql 3.0002_5.
-Dom
--------------010107060505040007010203
Content-Type: text/plain;
name="dbd-mysql-utf8.patch"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="dbd-mysql-utf8.patch"
ZGlmZiAtdXJOIERCRC1teXNxbC0zLjAwMDJfNS9NQU5JRkVTVCBEQkQtbXlz cWwtMy4wMDAy
XzUuZG9tL01BTklGRVNUCi0tLSBEQkQtbXlzcWwtMy4wMDAyXzUvTUFOSUZF U1QJMjAwNS0w
OS0yNyAwMDoxNTowMS4wMDAwMDAwMDAgKzAxMDAKKysrIERCRC1teXNxbC0z LjAwMDJfNS5k
b20vTUFOSUZFU1QJMjAwNi0wMy0wNyAxMTowMzo0My4wMDAwMDAwMDAgKzAw MDAKQEAgLTIx
LDYgKzIxLDcgQEAKIHQvbXlzcWwuZGJ0ZXN0CiB0L215c3FsLnQKIHQvbXlz cWwyLnQKK3Qv
dXRmOC50CiBsaWIvREJEL215c3FsL0dldEluZm8ucG0KIGxpYi9EQkQvbXlz cWwvSU5TVEFM
TC5wb2QKIGxpYi9EQkQvbXlzcWwucG0KZGlmZiAtdXJOIERCRC1teXNxbC0z LjAwMDJfNS9k
YmRpbXAuYyBEQkQtbXlzcWwtMy4wMDAyXzUuZG9tL2RiZGltcC5jCi0tLSBE QkQtbXlzcWwt
My4wMDAyXzUvZGJkaW1wLmMJMjAwNi0wMi0wMSAyMjo0OTowMi4wMDAwMDAw MDAgKzAwMDAK
KysrIERCRC1teXNxbC0zLjAwMDJfNS5kb20vZGJkaW1wLmMJMjAwNi0wMy0w NyAxMzo0ODo1
Ny44NDY0NTAyMTEgKzAwMDAKQEAgLTEzODMsNiArMTM4MywxNyBAQAogICAg ICAgICAgICAg
ICAgICAgICAgICAgaW1wX2RiaC0+dXNlX3NlcnZlcl9zaWRlX3ByZXBhcmUp OwogI2VuZGlm
CiAKKyNpZiBkZWZpbmVkKHN2X3V0ZjhfZGVjb2RlKSAmJiBNWVNRTF9WRVJT SU9OX0lEID49
U0VSVkVSX1BSRVBBUkVfVkVSU0lPTgorICAgICAgICBpZiAoKHN2cCA9IGh2 X2ZldGNoKGh2
LCAibXlzcWxfZW5hYmxlX3V0ZjgiLCAxNywgRkFMU0UpKSAmJiAqc3ZwKSB7 CisgICAgICAg
ICAgLyogRG8gbm90IHRvdWNoIGltcF9kYmgtPmVuYWJsZV91dGY4IGFzIHdl IGFyZSBjYWxs
ZWQgZWFybGllcgorICAgICAgICAgICAqIHRoYW4gaXQgaXMgc2V0IGFuZCBt eXNxbF9vcHRp
b25zKCkgbXVzdCBiZSBiZWZvcmU6CisgICAgICAgICAgICogbXlzcWxfcmVh bF9jb25uZWN0
KCkKKwkgICAqLworCSAgbXlzcWxfb3B0aW9ucyhzb2NrLCBNWVNRTF9TRVRf Q0hBUlNFVF9O
QU1FLAorCSAgICAgICAgICAgICAgICAoU3ZUUlVFKCpzdnApID8gInV0Zjgi IDogImxhdGlu
MSIpKTsKKyAgICAgICAgfQorI2VuZGlmCisKICNpZiBkZWZpbmVkKERCRF9N WVNRTF9XSVRI
X1NTTCkgJiYgIWRlZmluZWQoREJEX01ZU1FMX0VNQkVEREVEKSAmJiBcCiAg ICAgKGRlZmlu
ZWQoQ0xJRU5UX1NTTCkgfHwgKE1ZU1FMX1ZFUlNJT05fSUQgPj0gNDAwMDAp KQogCWlmICgo
c3ZwID0gaHZfZmV0Y2goaHYsICJteXNxbF9zc2wiLCA5LCBGQUxTRSkpICAm JiAgKnN2cCkK
QEAgLTE1ODcsNiArMTU5OCwxMCBAQAogIC8qIFNhZmVyIHdlIGZsaXAgdGhp cyB0byBUUlVF
IHBlcmwgc2lkZSBpZiB3ZSBkZXRlY3QgYSBtb2RfcGVybCBlbnYuICovCiAg IGltcF9kYmgt
PmF1dG9fcmVjb25uZWN0ID0gRkFMU0U7CiAKKyNpZiBkZWZpbmVkKHN2X3V0 ZjhfZGVjb2Rl
KSAmJiBNWVNRTF9WRVJTSU9OX0lEID49U0VSVkVSX1BSRVBBUkVfVkVSU0lP TgorICBpbXBf
ZGJoLT5lbmFibGVfdXRmOCA9IEZBTFNFOyAgLyogaW5pdGlhbGl6ZSBteXNx bF9lbmFibGVf
dXRmOCAqLworI2VuZGlmCisKICAgaWYgKCFteV9sb2dpbihkYmgsIGltcF9k YmgpKQogICB7
CiAgICAgZG9fZXJyb3IoZGJoLCBteXNxbF9lcnJubygmaW1wX2RiaC0+bXlz cWwpLApAQCAt
MTkwMyw2ICsxOTE4LDEwIEBACiAKICAgZWxzZSBpZiAoa2wgPT0gMzEgJiYg c3RyRVEoa2V5
LCJteXNxbF91bnNhZmVfYmluZF90eXBlX2d1ZXNzaW5nIikpCiAJaW1wX2Ri aC0+YmluZF90
eXBlX2d1ZXNzaW5nID0gU3ZJVih2YWx1ZXN2KTsKKyNpZiBkZWZpbmVkKHN2 X3V0ZjhfZGVj
b2RlKSAmJiBNWVNRTF9WRVJTSU9OX0lEID49U0VSVkVSX1BSRVBBUkVfVkVS U0lPTgorICBl
bHNlIGlmIChrbCA9PSAxNyAmJiBzdHJFUShrZXksICJteXNxbF9lbmFibGVf dXRmOCIpKQor
ICAgIGltcF9kYmgtPmVuYWJsZV91dGY4ID0gYm9vbF92YWx1ZTsKKyNlbmRp ZgogICBlbHNl
CiAgICAgcmV0dXJuIEZBTFNFOwkJCQkvKiBVbmtub3duIGtleSAqLwogCkBA IC0xOTkzLDYg
KzIwMTIsMTAgQEAKICAgICAgIGNvbnN0IGNoYXIqIG1zZyA9IG15c3FsX2Vy cm9yKCZpbXBf
ZGJoLT5teXNxbCk7CiAgICAgICByZXN1bHQ9IHN2XzJtb3J0YWwobmV3U1Zw dihtc2csIHN0
cmxlbihtc2cpKSk7CiAgICAgfQorI2lmIGRlZmluZWQoc3ZfdXRmOF9kZWNv ZGUpICYmIE1Z
U1FMX1ZFUlNJT05fSUQgPj1TRVJWRVJfUFJFUEFSRV9WRVJTSU9OCisgICAg ZWxzZSBpZiAo
a2wgPT0gc3RybGVuKCJlbmFibGVfdXRmOCIpICYmIHN0ckVRKGtleSwgImVu YWJsZV91dGY4
IikpCisgICAgICAgIHJlc3VsdCA9IHN2XzJtb3J0YWwobmV3U1ZpdihpbXBf ZGJoLT5lbmFi
bGVfdXRmOCkpOworI2VuZGlmCiAgICAgYnJlYWs7CiAKICAgY2FzZSAnZCc6 CkBAIC0zMjg3
LDYgKzMzMTAsMTAgQEAKICAgICAgICAgICBpZiAoZGJpcy0+ZGVidWcgPj0g MikKICAgICAg
ICAgICAgIFBlcmxJT19wcmludGYoREJJTE9HRlAsICJzdF9mZXRjaCBzdHJp bmcgZGF0YSAl
c1xuIiwgZmJoLT5kYXRhKTsKICAgICAgICAgICBzdl9zZXRwdm4oc3YsIGZi aC0+ZGF0YSwg
ZmJoLT5sZW5ndGgpOworI2lmZGVmIHN2X3V0ZjhfZGVjb2RlCisgICAgICAg ICAgaWYoaW1w
X2RiaC0+ZW5hYmxlX3V0ZjgpCisgICAgICAgICAgICAgIHN2X3V0ZjhfZGVj b2RlKHN2KTsK
KyNlbmRpZgogICAgICAgICAgIGJyZWFrOwogCiAgICAgICAgIGRlZmF1bHQ6 CkBAIC00MjU2
LDYgKzQyODMsMTAgQEAKIAogICAgIHB0cj0gU3ZQVihzdHIsIGxlbik7CiAg ICAgcmVzdWx0
PSBuZXdTVihsZW4qMiszKTsKKyNpZmRlZiBTdlVURjgKKyAgICBpZiAoU3ZV VEY4KHN0cikp
IFN2VVRGOF9vbihyZXN1bHQpOworI2VuZGlmCisKICAgICBzcHRyPSBTdlBW WChyZXN1bHQp
OwogCiAgICAgKnNwdHIrKyA9ICdcJyc7CmRpZmYgLXVyTiBEQkQtbXlzcWwt My4wMDAyXzUv
ZGJkaW1wLmggREJELW15c3FsLTMuMDAwMl81LmRvbS9kYmRpbXAuaAotLS0g REJELW15c3Fs
LTMuMDAwMl81L2RiZGltcC5oCTIwMDYtMDItMDEgMTk6NTI6MjUuMDAwMDAw MDAwICswMDAw
CisrKyBEQkQtbXlzcWwtMy4wMDAyXzUuZG9tL2RiZGltcC5oCTIwMDYtMDMt MDcgMTE6MDI6
MDEuMDAwMDAwMDAwICswMDAwCkBAIC0xNDMsNiArMTQzLDkgQEAKICAgICAg ICAgICAgICAg
ICAgICAgICAgICAgICAgICAqLwogICAgIGludCB1c2Vfc2VydmVyX3NpZGVf cHJlcGFyZTsK
ICAgICBpbnQgaGFzX2F1dG9kZXRlY3RfcHJlcGFyZTsKKyNpZiBkZWZpbmVk KHN2X3V0Zjhf
ZGVjb2RlKSAmJiBNWVNRTF9WRVJTSU9OX0lEID49U0VSVkVSX1BSRVBBUkVf VkVSU0lPTgor
ICAgIGJvb2wgZW5hYmxlX3V0Zjg7CisjZW5kaWYKIH07CiAKIApkaWZmIC11 ck4gREJELW15
c3FsLTMuMDAwMl81L2xpYi9EQkQvbXlzcWwucG0gREJELW15c3FsLTMuMDAw Ml81LmRvbS9s
aWIvREJEL215c3FsLnBtCi0tLSBEQkQtbXlzcWwtMy4wMDAyXzUvbGliL0RC RC9teXNxbC5w
bQkyMDA2LTAyLTAxIDIyOjQ3OjI0LjAwMDAwMDAwMCArMDAwMAorKysgREJE LW15c3FsLTMu
MDAwMl81LmRvbS9saWIvREJEL215c3FsLnBtCTIwMDYtMDMtMDcgMTI6NTE6 NDguMDAwMDAw
MDAwICswMDAwCkBAIC05NTUsNiArOTU1LDIwIEBACiBJdCBpcyBwb3NzaWJs ZSB0byBzZXQv
dW5zZXQgdGhlIEM8bXlzcWxfdXNlX3Jlc3VsdD4gYXR0cmlidXRlIGFmdGVy IAogY3JlYXRp
b24gb2Ygc3RhdGVtZW50IGhhbmRsZS4gU2VlIGJlbG93LgogCis9aXRlbSBt eXNxbF9lbmFi
bGVfdXRmOAorCitUaGlzIGF0dHJpYnV0ZSBkZXRlcm1pbmVzIHdoZXRoZXIg REJEOjpteXNx
bCBzaG91bGQgYXNzdW1lIHN0cmluZ3MKK3N0b3JlZCBpbiB0aGUgZGF0YWJh c2UgYXJlIHV0
ZjguICBUaGlzIGZlYXR1cmUgZGVmYXVsdHMgdG8gb2ZmLgorCitXaGVuIHNl dCwgYSBkYXRh
IHJldHJpZXZlZCBmcm9tIGEgdGV4dHVhbCBjb2x1bW4gdHlwZSAoY2hhciwg dmFyY2hhciwK
K2V0Yykgd2lsbCBoYXZlIHRoZSBVVEYtOCBmbGFnIHR1cm5lZCBvbiBpZiBu ZWNlc3Nhcnku
ICBUaGlzIGVuYWJsZXMKK2NoYXJhY3RlciBzZW1hbnRpY3Mgb24gdGhhdCBz dHJpbmcuCisK
K0FkZGl0aW9uYWxseSwgdHVybmluZyBvbiB0aGlzIGZsYWcgdGVsbHMgTXlT UUwgdGhhdCBp
bmNvbWluZyBkYXRhIHNob3VsZAorYmUgdHJlYXRlZCBhcyBVVEYtOC4gIFRo aXMgd2lsbCBv
bmx5IHRha2UgZWZmZWN0IGlmIHVzZWQgYXMgcGFydCBvZiB0aGUKK2NhbGwg dG8gY29ubmVj
dCgpLgorCitUaGlzIG9wdGlvbiBpcyBleHBlcmltZW50YWwgYW5kIG1heSBj aGFuZ2UgaW4g
ZnV0dXJlIHZlcnNpb25zLgogCiA9aGVhZDEgU1RBVEVNRU5UIEhBTkRMRVMK IApkaWZmIC11
ck4gREJELW15c3FsLTMuMDAwMl81L3QvdXRmOC50IERCRC1teXNxbC0zLjAw MDJfNS5kb20v
dC91dGY4LnQKLS0tIERCRC1teXNxbC0zLjAwMDJfNS90L3V0ZjgudAkxOTcw LTAxLTAxIDAx
OjAwOjAwLjAwMDAwMDAwMCArMDEwMAorKysgREJELW15c3FsLTMuMDAwMl81 LmRvbS90L3V0
ZjgudAkyMDA2LTAzLTA3IDEzOjQ3OjA1LjcwNjU2MDEzNSArMDAwMApAQCAt MCwwICsxLDEy
MyBAQAorIyEvdXNyL2xvY2FsL2Jpbi9wZXJsCisjCisjICAgJElkJAorIwor IyAgIFRoaXMg
Y2hlY2tzIGZvciBVVEYtOCBzdXBwb3J0LgorIworCisKKyMKKyMgICBNYWtl IC13IGhhcHB5
CisjCit1c2UgdmFycyBxdygkdGVzdF9kc24gJHRlc3RfdXNlciAkdGVzdF9w YXNzd29yZCAk
bWRyaXZlciAkdmVyYm9zZSAkc3RhdGUKKwkgICAgJGRiZHJpdmVyKTsKK3Vz ZSB2YXJzIHF3
KCRDT0xfTlVMTEFCTEUgJENPTF9LRVkpOworJHRlc3RfZHNuID0gJyc7Cisk dGVzdF91c2Vy
ID0gJyc7CiskdGVzdF9wYXNzd29yZCA9ICcnOworCisKKyMKKyMgICBJbmNs dWRlIGxpYi5w
bAorIwordXNlIERCSTsKK3VzZSBzdHJpY3Q7CiskbWRyaXZlciA9ICIiOwor eworICAgIG15
ICRmaWxlOworICAgIGZvcmVhY2ggJGZpbGUgKCJsaWIucGwiLCAidC9saWIu cGwiKSB7CisJ
ZG8gJGZpbGU7IGlmICgkQCkgeyBwcmludCBTVERFUlIgIkVycm9yIHdoaWxl IGV4ZWN1dGlu
ZyBsaWIucGw6ICRAXG4iOworCQkJICAgIGV4aXQgMTA7CisJCQl9CisJaWYg KCRtZHJpdmVy
IG5lICcnKSB7CisJICAgIGxhc3Q7CisJfQorICAgIH0KK30KKworc3ViIFNl cnZlckVycm9y
KCkgeworICAgIHByaW50IFNUREVSUiAoIkNhbm5vdCBjb25uZWN0OiAiLCAk REJJOjplcnJz
dHIsICJcbiIsCisJIlx0RWl0aGVyIHlvdXIgc2VydmVyIGlzIG5vdCB1cCBh bmQgcnVubmlu
ZyBvciB5b3UgaGF2ZSBub1xuIiwKKwkiXHRwZXJtaXNzaW9ucyBmb3IgYWNl c3NpbmcgdGhl
IERTTiAkdGVzdF9kc24uXG4iLAorCSJcdFRoaXMgdGVzdCByZXF1aXJlcyBh IHJ1bm5pbmcg
c2VydmVyIGFuZCB3cml0ZSBwZXJtaXNzaW9ucy5cbiIsCisJIlx0UGxlYXNl IG1ha2Ugc3Vy
ZSB5b3VyIHNlcnZlciBpcyBydW5uaW5nIGFuZCB5b3UgaGF2ZVxuIiwKKwki XHRwZXJtaXNz
aW9ucywgdGhlbiByZXRyeS5cbiIpOworICAgIGV4aXQgMTA7Cit9CisKKyMK KyMgICBNYWlu
IGxvb3A7IGxlYXZlIHRoaXMgdW50b3VjaGVkLCBwdXQgdGVzdHMgYWZ0ZXIg Y3JlYXRpbmcK
KyMgICB0aGUgbmV3IHRhYmxlLgorIword2hpbGUgKFRlc3RpbmcoKSkgewor ICAgIG15ICgk
ZGJoLCAkc3RoLCAkcXVlcnkpOworCisgICAgIworICAgICMgICBDb25uZWN0 IHRvIHRoZSBk
YXRhYmFzZQorICAgIFRlc3QoJHN0YXRlIG9yICgkZGJoID0gREJJLT5jb25u ZWN0KCR0ZXN0
X2RzbiwgJHRlc3RfdXNlciwKKwkJCQkJJHRlc3RfcGFzc3dvcmQsIHtteXNx bF9lbmFibGVf
dXRmOCA9PiAxfSkpKQorCSAgIG9yIFNlcnZlckVycm9yKCk7CisKKyAgICAj CisgICAgIyAg
IEZpbmQgYSBwb3NzaWJsZSBuZXcgdGFibGUgbmFtZQorICAgICMKKyAgICBt eSAkdGFibGUg
PSAnJzsKKyAgICBUZXN0KCRzdGF0ZSBvciAkdGFibGUgPSBGaW5kTmV3VGFi bGUoJGRiaCkp
CisJICAgb3IgRXJyTXNnRigiQ2Fubm90IGRldGVybWluZSBhIGxlZ2FsIHRh YmxlIG5hbWU6
IEVycm9yICVzLlxuIiwKKwkJICAgICAgJGRiaC0+ZXJyc3RyKTsKKworICAg ICMKKyAgICAj
ICAgQ3JlYXRlIGEgbmV3IHRhYmxlOyBFRElUIFRISVMhCisgICAgIworICAg IFRlc3QoJHN0
YXRlIG9yICgkcXVlcnkgPSBUYWJsZURlZmluaXRpb24oJHRhYmxlLAorCQkJ CSAgICAgIFsi
bmFtZSIsICJDSEFSIiwgICAgNjQsICRDT0xfTlVMTEFCTEVdKSwKKwkJICAg ICRkYmgtPmRv
KCRxdWVyeSkpKQorCW9yIEVyck1zZ0YoIkNhbm5vdCBjcmVhdGUgdGFibGU6 IEVycm9yICVz
LlxuIiwKKwkJICAgICAgJGRiaC0+ZXJyc3RyKTsKKworCisgICAgIworICAg ICMgICBhbmQg
aGVyZSdzIHRoZSByaWdodCBwbGFjZSBmb3IgaW5zZXJ0aW5nIG5ldyB0ZXN0 czoKKyAgICAj
CisKKyAgICBteSAkdXRmOF9zdHIgICAgICAgID0gIlx4ezAxMDB9ZGFtIjsg ICAgICMgIkFk
YW0iIHdpdGggYSBtYWNyb24uCisgICAgbXkgJHF1b3RlZF91dGY4X3N0ciA9 ICInXHh7MDEw
MH1kYW0nIjsKKyAgICBUZXN0KCAkc3RhdGUgb3IgKCAkZGJoLT5xdW90ZSgg JHV0Zjhfc3Ry
ICkgZXEgJHF1b3RlZF91dGY4X3N0ciApICkKKyAgICAgIG9yIEVyck1zZygg IkZhaWxlZCB0
byByZXRhaW4gVVRGLTggZmxhZyB3aGVuIHF1b3RlaW5nLlxuIiApOworCisg ICAgVGVzdCgg
JHN0YXRlIG9yICggJGRiaC0+eyBteXNxbF9lbmFibGVfdXRmOCB9ICkgKQor ICAgICAgb3Ig
RXJyTXNnKCAibXlzcWxfZW5hYmxlX3V0ZjggZGlkbid0IHN1cnZpdmUgY29u bmVjdCgpXG4i
ICk7CisKKyAgICAkcXVlcnkgPSBxcXtJTlNFUlQgSU5UTyAkdGFibGUgKG5h bWUpIFZBTFVF
UyAoPyl9OworICAgIFRlc3QoICRzdGF0ZSBvciAkZGJoLT5kbyggJHF1ZXJ5 LCB7fSwgJHV0
Zjhfc3RyICkgKQorICAgICAgb3IgRXJyTXNnRiggIklOU0VSVCBmYWlsZWQ6 IHF1ZXJ5ICRx
dWVyeSwgZXJyb3IgJXMuXG4iLCAkZGJoLT5lcnJzdHIgKTsKKworICAgICRx dWVyeSA9ICJT
RUxFQ1QgbmFtZSBGUk9NICR0YWJsZSBMSU1JVCAxIjsKKyAgICBUZXN0KCAk c3RhdGUgb3Ig
KCRzdGggPSAkZGJoLT5wcmVwYXJlKCAkcXVlcnkgKSApICkKKyAgICAgIG9y IEVyck1zZ0Yo
ICJwcmVwYXJlIGZhaWxlZDogcXVlcnkgJHF1ZXJ5LCBlcnJvciAlcy5cbiIs ICRkYmgtPmVy
cnN0ciApOworCisgICAgVGVzdCgkc3RhdGUgb3IgJHN0aC0+ZXhlY3V0ZSkK KyAgICAgIG9y
IEVyck1zZ0YoICJleGVjdXRlIGZhaWxlZDogcXVlcnkgJHF1ZXJ5LCBlcnJv ciAlcy5cbiIs
ICRkYmgtPmVycnN0ciApOworCisgICAgbXkgJHJlZjsKKyAgICBUZXN0KCAk c3RhdGUgb3Ig
ZGVmaW5lZCggJHJlZiA9ICRzdGgtPmZldGNocm93X2FycmF5cmVmICkgKQor ICAgICAgb3Ig
RXJyTXNnRiggImZldGNoIGZhaWxlZDogcXVlcnkgJHF1ZXJ5LCBlcnJvciAl cy5cbiIsICRz
dGgtPmVycnN0ciApOworCisgICAgIyBGaW5hbGx5LCBjaGVjayB0aGF0IHdl IGdvdCBiYWNr
IFVURi04IGNvcnJlY3RseS4KKyAgICBUZXN0KCAkc3RhdGUgb3IgKCRyZWYt PlswXSBlcSAk
dXRmOF9zdHIpICkKKyAgICAgIG9yIEVyck1zZ0YoICJnb3QgYmFjayAnJHJl Zi0+WzBdJyBp
bnN0ZWFkIG9mICckdXRmOF9zdHInLlxuIiApOworCisgICAgVGVzdCggJHN0 YXRlIG9yICRz
dGgtPmZpbmlzaCApCisgICAgICBvciBFcnJNc2dGKCAiQ2Fubm90IGZpbmlz aDogJXMuXG4i
LCAkc3RoLT5lcnJzdHIgKTsKKworICAgICMKKyAgICAjICAgRmluYWxseSBk cm9wIHRoZSB0
ZXN0IHRhYmxlLgorICAgICMKKyAgICBUZXN0KCRzdGF0ZSBvciAkZGJoLT5k bygiRFJPUCBU
QUJMRSAkdGFibGUiKSkKKwkgICBvciBFcnJNc2dGKCJDYW5ub3QgRFJPUCB0 ZXN0IHRhYmxl
ICR0YWJsZTogJXMuXG4iLAorCQkgICAgICAkZGJoLT5lcnJzdHIpOworCisg ICAgIyAgIC4u
LiBhbmQgZGlzY29ubmVjdAorICAgIFRlc3QoJHN0YXRlIG9yICRkYmgtPmRp c2Nvbm5lY3Qp
CisJb3IgRXJyTXNnRigiQ2Fubm90IGRpc2Nvbm5lY3Q6ICVzLlxuIiwgJGRi aC0+ZXJybXNn
KTsKK30K
--------------010107060505040007010203
Content-Type: text/plain; charset=us-ascii
--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org
--------------010107060505040007010203--