view release on metacpan or  search on metacpan

Changes.historic  view on Meta::CPAN

  Parameters must start with a hyphen, so treat all options without leading
  hyphen in mysql_config --libs output as libraries with full path.
  Partially fixes bug https://rt.cpan.org/Public/Bug/Display.html?id=100898
  Fix by Pali Rohár.
* Fix support for magic scalars (pali)
   (https://github.com/perl5-dbi/DBD-mysql/pull/76)

2016-12-12 Patrick Galbraith, Michiel Beijen, DBI/DBD community (4.041_1)
* Unicode fixes: when using mysql_enable_utf8 or mysql_enable_utf8mb4,
  previous versions of DBD::mysql did not properly encode input statements
  to UTF-8 and retrieved columns were always UTF-8 decoded regardless of the
  column charset.
  Fix by Pali Rohár.
  Reported and feedback on fix by Marc Lehmann
  (https://rt.cpan.org/Public/Bug/Display.html?id=87428)
  Also, the UTF-8 flag was not set for decoded data:
  (https://rt.cpan.org/Public/Bug/Display.html?id=53130)
* Return INTs with ZEROFILL as strings. Reported by Knarf, fix by Pali Rohár.
  (https://rt.cpan.org/Public/Bug/Display.html?id=118977)

2016-11-28 Patrick Galbraith, Michiel Beijen, DBI/DBD community (4.041)
* Fix use-after-free for repeated fetchrow_arrayref calls when
  mysql_server_prepare=1

  Function dbd_st_fetch() via Renew() can reallocate output buffer for
  mysql_stmt_fetch() call. But it does not update pointer to that buffer in

lib/DBD/MariaDB.pod  view on Meta::CPAN

Perl scalars do not distinguish between binary I<byte> orientated buffers and
I<Unicode> orientated strings. In Perl it is always up to the caller and the
callee to define in its API if functions and methods expect I<byte> buffers or
I<Unicode> strings. It is not possible (or rather Perl application should not
try) to distinguish if Perl scalar contains a I<byte> buffer or I<Unicode>
string.

When fetching data from MariaDB and MySQL servers, DBD::MariaDB treats all
fields marked with MySQL's charset C<utf8mb4> (and also C<utf8>) as I<Unicode>
strings. Everything else is treated as binary I<byte> oriented buffers.
Therefore, the only difference is that UTF-8 fields are automatically decoded to
Unicode. Binary blob fields remain untouched and corresponding Perl scalars
would contain just ordinals C<0..255> (classic sequence of bytes). Unicode
string scalars would contain sequence of Unicode code points.

There is a small problem with input data, more preciously with SQL statements
and their bind parameters. By definition a SQL statement is a string and
therefore it is expected and handled by DBD::MariaDB as a I<Unicode> string (not
I<byte> oriented buffer). There is no way to treat a SQL statement as a binary,
but this is not a problem. All SQL commands are encoded in ASCII and all ASCII
characters are invariants in UTF-8 (have the same representation as a sequence