Re: Fork DBD::mysql

[pali]

On Wednesday 11 October 2017 15:09:49 Steven Lembark wrote:
> 
> > It is not as easy as it could appear. And also in some cases migration
> > from MySQL/MariaDB to Pg could be problematic from performance point of
> > view. One Pg developer already told us that for our use case is really
> > MySQL better then Pg.
> 
> Q: What about your use case is more adapted to MySQL? 
> 
> There is no part of SQL that Pg does not support that MySQL does; there
> should not be any serious performance issues with Pg that leave it 
> slower than MySQL. There are a variety of ways that Pg can be faster
> (e.g., partial indexes, exclusion constraints vs. triggers) and will
> usually be less error-prone. You may have to refactor some sloppy design
> that MySQL allowed but Pg does not, but that is also in your favor.
> 
> I really am curious to see any example of something in your database that
> can be handled more gracefully in MySQL than well-designed Pg.

Hi! The use case is massive updates of existing columns in huge table.
Updates of columns in Pg are done just in linked-list until autovacuum
cleanups older values. If there are too many updates, then select
queries are slower. I do not know if new version of Pg have better
performance for such use case, but year (or two?) I was told that by Pg
developer that for such usage is MySQL still better.

Re: Fork DBD::mysql

[Wm Mussatto]

On Wed, October 11, 2017 12:10, Darren Duncan wrote:
> On 2017-10-11 10:05 AM, Vincent Veyron wrote:
>> On Wed, 11 Oct 2017 15:09:49 +
>> Steven Lembark  wrote:
>>
>>> I really am curious to see any example of something in your database
>>> that
>>> can be handled more gracefully in MySQL than well-designed Pg.
>>
>> Seconded, I was wondering the same thing.
>
> While we're on that wagon, thirded.
>
> -- Darren Duncan
Haven't used Pg for a while, have they resolved the issue where it would
lockup for periods doing automatic database re-organization/table space
compression.  We used it for Bayes filtering.

--
William R. Mussatto
Systems Engineer
http://www.csz.com
909-920-9154

Re: Fork DBD::mysql

[Darren Duncan]

On 2017-10-11 10:05 AM, Vincent Veyron wrote:

On Wed, 11 Oct 2017 15:09:49 +
Steven Lembark  wrote:


I really am curious to see any example of something in your database that
can be handled more gracefully in MySQL than well-designed Pg.


Seconded, I was wondering the same thing.


While we're on that wagon, thirded.

-- Darren Duncan

Re: Fork DBD::mysql

[Vincent Veyron]

On Wed, 11 Oct 2017 15:09:49 +
Steven Lembark  wrote:


> I really am curious to see any example of something in your database that
> can be handled more gracefully in MySQL than well-designed Pg.
> 

Seconded, I was wondering the same thing.


-- 
Bien à vous, Vincent Veyron 

https://compta.libremen.com
Logiciel de comptabilité, libre

Re: Fork DBD::mysql

[Steven Lembark]

> It is not as easy as it could appear. And also in some cases migration
> from MySQL/MariaDB to Pg could be problematic from performance point of
> view. One Pg developer already told us that for our use case is really
> MySQL better then Pg.

Q: What about your use case is more adapted to MySQL? 

There is no part of SQL that Pg does not support that MySQL does; there
should not be any serious performance issues with Pg that leave it 
slower than MySQL. There are a variety of ways that Pg can be faster
(e.g., partial indexes, exclusion constraints vs. triggers) and will
usually be less error-prone. You may have to refactor some sloppy design
that MySQL allowed but Pg does not, but that is also in your favor.

I really am curious to see any example of something in your database that
can be handled more gracefully in MySQL than well-designed Pg.


-- 
Steven Lembark 3646 Flora Pl
Workhorse Computing   St Louis, MO 63110
lemb...@wrkhors.com  +1 888 359 3508

Re: Fork DBD::mysql

[pali]

On Friday 01 September 2017 17:01:49 Patrick M. Galbraith wrote:
> Hi Pali,
> 
> I would very much like to address these issues and fix the UTF issue you so
> kindly had a patch for that people had problems with and do so in a way that
> doesn't require forking. I'm very sorry about this as I was in between jobs
> and distracted but am free next week to discuss this. I am also talking to
> my former Mysql colleagues at Oracle and MariaDB (Reggie, Matt, Georg) about
> moving this forward and get the driver MySQL 8 compatible. I would like to
> have a discussion to make this happen. How would you-- and everyone
> interested in this list-- like to work with me and others to solve this
> issue?
> 
> Kind regards,
> 
> Patrick

Hi! Welcome back! I would prefer discussion here on the dbi-dev mailing
list, so other people can watch current situation and also participate
in development discussion in open form.

Re: Fork DBD::mysql

[Patrick M. Galbraith]

Hi Pali,

I would very much like to address these issues and fix the UTF issue you 
so kindly had a patch for that people had problems with and do so in a 
way that doesn't require forking. I'm very sorry about this as I was in 
between jobs and distracted but am free next week to discuss this. I am 
also talking to my former Mysql colleagues at Oracle and MariaDB 
(Reggie, Matt, Georg) about moving this forward and get the driver MySQL 
8 compatible. I would like to have a discussion to make this happen. How 
would you-- and everyone interested in this list-- like to work with me 
and others to solve this issue?


Kind regards,

Patrick

On 8/28/17 11:55 AM, p...@cpan.org wrote:

Hello, 2 months passed since two security problems related to DBD::mysql
were reported, namely CVE-2017-10789 and CVE-2017-10788. Looking at the
DBD::mysql github project page and RT bugtracker, it can be seen that
nothing has happened for 2 months. Some people are asking or waiting for
reported problems to be fixed... Without an answer.

A long discussion was started in April by a group of people who didn't
like the improvements and didn't want to see the bugs fixed in
DBD::mysql driver due to the fact that they probably had old and buggy
legacy code which wouldn't work after DBD::mysql starts fixing bugs.

 From what happened it looks like that this group of people forced
DBD::mysql maintainers to revert all DBD::mysql changes (with all bug
fixes including security ones). And because nothing has happened for 2
months, that looks like fixing those bugs is not planned.

This means just one thing:

   DBD::mysql is dead right now :-(

There are no new commit for 2 months, no evidence of any activity. And
it looks like this is what that group of people wanted. They haven't
written anything, neither any comment about open security issues, nor
any comment that they forced maintainers to revert a security related
bug fix. Probably they don't have to fix their own code and they can use
the last released version of DBD::mysql. Perfect for them, probably a
catastrophe for all others which don't want to use probably-vulnerable
code.

But it also means that it isn't possible to compile the last DBD::mysql
with the new MySQL 8 or new MariaDB versions. More linux distributions
started to pack/bundle their own DBD::mysql patches just because they
need to build DBD::mysql into their repositories with upgraded MariaDB.

I need to say that such situation is not acceptable for *any* future or
new development in Perl which uses either MySQL or MariaDB database.

DBD::mysql has couple of bugs (some are security released) and fully
non-working UTF-8/Unicode support. It means that any internationalized
applications which use MySQL are hard to write in Perl.

Because of the current situation we in the GoodData company are thinking
about forking DBD::mysql. We use DBI not only with DBD::mysql, but also
with DBD::Pg. The annoying bugs in DBD::mysql still require hacks and
workarounds, while similar bugs were fixed in DBD::Pg years ago. Also,
inability to use the new version of MySQL or MariaDB is a problem. Same
for the open security issues.

I would like to ask, whether somebody else is interested in DBD::mysql
fork? Either as a user or as a developer? Maintaining a fork isn't a
simple task, but with supporting users and contributing developers it
should be easier.

And specially, are MariaDB developers interested in fixing/improving
DBD::mysql fork, so Perl could work better with MariaDB servers? At
least it would be able to compile against the new MariaDB C-client?

Re: Fork DBD::mysql

[pali]

On Friday 01 September 2017 13:36:13 H.Merijn Brand wrote:
> On Fri, 1 Sep 2017 13:08:17 +0200, p...@cpan.org wrote:
> 
> > On Tuesday 29 August 2017 22:08:09 Dan Book wrote:
> > > Though the reversion was made with good intentions of preserving back
> > > compat in the short term, it was accompanied by a promise of reapplying 
> > > the
> > > many important fixes that were reverted (
> > > https://github.com/perl5-dbi/DBD-mysql/compare/4.041...4.042 ) as well as
> > > re-adding a correct utf8 encoding option, as it is still necessary to fix
> > > this broken behavior one way or another. Since nothing has happened,
> > > forking may be the only reasonable option. We are currently version pinned
> > > to 4.042 as "upgrading" to 4.043 would be a massive regression in our
> > > codebase.
> > > 
> > > -Dan  
> > 
> > Ok, I understood Dan's email as there are already users who cannot
> > upgrade to the last DBD::mysql version (where revert happened) as it
> > contains bugs...
> > 
> > And due to big silent, I would say that DBD::mysql is really dead.
> 
> I doubt that. Maybe the active maintainer is on holiday. It is the
> season you know.
> 
> June is indeed a few months ago, but it was still this year. NOT dead.
> Please try to contact Michiel first.

I already did it and also I CCed him in my first email in this thread.

> Author: Michiel Beijen   2017-06-29 11:25:48
> Committer: Michiel Beijen   2017-06-29 11:30:07
> Tags: 4.043
> Parent: 1ece6b4b8630a1cf348373aa41cbe5f748dcd62a (Merge pull request #137 
> from pali/versions)
> Branch: remotes/origin/master
> Follows: 4.042
> Precedes: 
> 
> New version 4.043 - the same as 4.041

Re: Fork DBD::mysql

[H.Merijn Brand]

On Fri, 1 Sep 2017 13:08:17 +0200, p...@cpan.org wrote:

> On Tuesday 29 August 2017 22:08:09 Dan Book wrote:
> > Though the reversion was made with good intentions of preserving back
> > compat in the short term, it was accompanied by a promise of reapplying the
> > many important fixes that were reverted (
> > https://github.com/perl5-dbi/DBD-mysql/compare/4.041...4.042 ) as well as
> > re-adding a correct utf8 encoding option, as it is still necessary to fix
> > this broken behavior one way or another. Since nothing has happened,
> > forking may be the only reasonable option. We are currently version pinned
> > to 4.042 as "upgrading" to 4.043 would be a massive regression in our
> > codebase.
> > 
> > -Dan  
> 
> Ok, I understood Dan's email as there are already users who cannot
> upgrade to the last DBD::mysql version (where revert happened) as it
> contains bugs...
> 
> And due to big silent, I would say that DBD::mysql is really dead.

I doubt that. Maybe the active maintainer is on holiday. It is the
season you know.

June is indeed a few months ago, but it was still this year. NOT dead.
Please try to contact Michiel first.

Author: Michiel Beijen   2017-06-29 11:25:48
Committer: Michiel Beijen   2017-06-29 11:30:07
Tags: 4.043
Parent: 1ece6b4b8630a1cf348373aa41cbe5f748dcd62a (Merge pull request #137 from 
pali/versions)
Branch: remotes/origin/master
Follows: 4.042
Precedes: 

New version 4.043 - the same as 4.041

-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.27   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/


pgpRKXC3u_LpT.pgp
Description: OpenPGP digital signature

Re: Fork DBD::mysql

[pali]

On Tuesday 29 August 2017 22:08:09 Dan Book wrote:
> Though the reversion was made with good intentions of preserving back
> compat in the short term, it was accompanied by a promise of reapplying the
> many important fixes that were reverted (
> https://github.com/perl5-dbi/DBD-mysql/compare/4.041...4.042 ) as well as
> re-adding a correct utf8 encoding option, as it is still necessary to fix
> this broken behavior one way or another. Since nothing has happened,
> forking may be the only reasonable option. We are currently version pinned
> to 4.042 as "upgrading" to 4.043 would be a massive regression in our
> codebase.
> 
> -Dan

Ok, I understood Dan's email as there are already users who cannot
upgrade to the last DBD::mysql version (where revert happened) as it
contains bugs...

And due to big silent, I would say that DBD::mysql is really dead.

Re: [External] Fork DBD::mysql

[Dan Book]

On Tue, Aug 29, 2017 at 3:36 AM,  wrote:

> Then users of MySQL would stay with DBD::mysql and they would not have
> fixed DBD driver. We were thinking about choosing DBD::mariadb name
> for our fork. But without dropping MySQL support, so also MySQL users
> could benefit from it.
>
> On Monday 28 August 2017 18:08:20 Daniël van Eeden wrote:
> > What about splitting it in DBD::mysql and DBD::mariadb ?
> >
> >
> > On 28 August 2017 5:55:09 p.m. p...@cpan.org wrote:
> >
> > >Hello, 2 months passed since two security problems related to DBD::mysql
> > >were reported, namely CVE-2017-10789 and CVE-2017-10788. Looking at the
> > >DBD::mysql github project page and RT bugtracker, it can be seen that
> > >nothing has happened for 2 months. Some people are asking or waiting for
> > >reported problems to be fixed... Without an answer.
> > >
> > >A long discussion was started in April by a group of people who didn't
> > >like the improvements and didn't want to see the bugs fixed in
> > >DBD::mysql driver due to the fact that they probably had old and buggy
> > >legacy code which wouldn't work after DBD::mysql starts fixing bugs.
> > >
> > >From what happened it looks like that this group of people forced
> > >DBD::mysql maintainers to revert all DBD::mysql changes (with all bug
> > >fixes including security ones). And because nothing has happened for 2
> > >months, that looks like fixing those bugs is not planned.
> > >
> > >This means just one thing:
> > >
> > >  DBD::mysql is dead right now :-(
> > >
> > >There are no new commit for 2 months, no evidence of any activity. And
> > >it looks like this is what that group of people wanted. They haven't
> > >written anything, neither any comment about open security issues, nor
> > >any comment that they forced maintainers to revert a security related
> > >bug fix. Probably they don't have to fix their own code and they can use
> > >the last released version of DBD::mysql. Perfect for them, probably a
> > >catastrophe for all others which don't want to use probably-vulnerable
> > >code.
> > >
> > >But it also means that it isn't possible to compile the last DBD::mysql
> > >with the new MySQL 8 or new MariaDB versions. More linux distributions
> > >started to pack/bundle their own DBD::mysql patches just because they
> > >need to build DBD::mysql into their repositories with upgraded MariaDB.
> > >
> > >I need to say that such situation is not acceptable for *any* future or
> > >new development in Perl which uses either MySQL or MariaDB database.
> > >
> > >DBD::mysql has couple of bugs (some are security released) and fully
> > >non-working UTF-8/Unicode support. It means that any internationalized
> > >applications which use MySQL are hard to write in Perl.
> > >
> > >Because of the current situation we in the GoodData company are thinking
> > >about forking DBD::mysql. We use DBI not only with DBD::mysql, but also
> > >with DBD::Pg. The annoying bugs in DBD::mysql still require hacks and
> > >workarounds, while similar bugs were fixed in DBD::Pg years ago. Also,
> > >inability to use the new version of MySQL or MariaDB is a problem. Same
> > >for the open security issues.
> > >
> > >I would like to ask, whether somebody else is interested in DBD::mysql
> > >fork? Either as a user or as a developer? Maintaining a fork isn't a
> > >simple task, but with supporting users and contributing developers it
> > >should be easier.
> > >
> > >And specially, are MariaDB developers interested in fixing/improving
> > >DBD::mysql fork, so Perl could work better with MariaDB servers? At
> > >least it would be able to compile against the new MariaDB C-client?
> > >
>

My reply yesterday seems to not have gone through, so I am replying again
here.

Though the reversion was made with good intentions of preserving back
compat in the short term, it was accompanied by a promise of reapplying the
many important fixes that were reverted (
https://github.com/perl5-dbi/DBD-mysql/compare/4.041...4.042 ) as well as
re-adding a correct utf8 encoding option, as it is still necessary to fix
this broken behavior one way or another. Since nothing has happened,
forking may be the only reasonable option. We are currently version pinned
to 4.042 as "upgrading" to 4.043 would be a massive regression in our
codebase.

-Dan

Re: Fork DBD::mysql

[pali]

On Monday 28 August 2017 09:19:46 Darren Duncan wrote:
> While a fork may be the best short term fix, as keeping up with security
> issues is important, I honestly believe that the best fix is to migrate to
> Postgres as soon as you can.

It is not as easy as it could appear. And also in some cases migration
from MySQL/MariaDB to Pg could be problematic from performance point of
view. One Pg developer already told us that for our use case is really
MySQL better then Pg.

Re: [External] Fork DBD::mysql

[pali]

Then users of MySQL would stay with DBD::mysql and they would not have
fixed DBD driver. We were thinking about choosing DBD::mariadb name
for our fork. But without dropping MySQL support, so also MySQL users
could benefit from it.

On Monday 28 August 2017 18:08:20 Daniël van Eeden wrote:
> What about splitting it in DBD::mysql and DBD::mariadb ?
> 
> 
> On 28 August 2017 5:55:09 p.m. p...@cpan.org wrote:
> 
> >Hello, 2 months passed since two security problems related to DBD::mysql
> >were reported, namely CVE-2017-10789 and CVE-2017-10788. Looking at the
> >DBD::mysql github project page and RT bugtracker, it can be seen that
> >nothing has happened for 2 months. Some people are asking or waiting for
> >reported problems to be fixed... Without an answer.
> >
> >A long discussion was started in April by a group of people who didn't
> >like the improvements and didn't want to see the bugs fixed in
> >DBD::mysql driver due to the fact that they probably had old and buggy
> >legacy code which wouldn't work after DBD::mysql starts fixing bugs.
> >
> >From what happened it looks like that this group of people forced
> >DBD::mysql maintainers to revert all DBD::mysql changes (with all bug
> >fixes including security ones). And because nothing has happened for 2
> >months, that looks like fixing those bugs is not planned.
> >
> >This means just one thing:
> >
> >  DBD::mysql is dead right now :-(
> >
> >There are no new commit for 2 months, no evidence of any activity. And
> >it looks like this is what that group of people wanted. They haven't
> >written anything, neither any comment about open security issues, nor
> >any comment that they forced maintainers to revert a security related
> >bug fix. Probably they don't have to fix their own code and they can use
> >the last released version of DBD::mysql. Perfect for them, probably a
> >catastrophe for all others which don't want to use probably-vulnerable
> >code.
> >
> >But it also means that it isn't possible to compile the last DBD::mysql
> >with the new MySQL 8 or new MariaDB versions. More linux distributions
> >started to pack/bundle their own DBD::mysql patches just because they
> >need to build DBD::mysql into their repositories with upgraded MariaDB.
> >
> >I need to say that such situation is not acceptable for *any* future or
> >new development in Perl which uses either MySQL or MariaDB database.
> >
> >DBD::mysql has couple of bugs (some are security released) and fully
> >non-working UTF-8/Unicode support. It means that any internationalized
> >applications which use MySQL are hard to write in Perl.
> >
> >Because of the current situation we in the GoodData company are thinking
> >about forking DBD::mysql. We use DBI not only with DBD::mysql, but also
> >with DBD::Pg. The annoying bugs in DBD::mysql still require hacks and
> >workarounds, while similar bugs were fixed in DBD::Pg years ago. Also,
> >inability to use the new version of MySQL or MariaDB is a problem. Same
> >for the open security issues.
> >
> >I would like to ask, whether somebody else is interested in DBD::mysql
> >fork? Either as a user or as a developer? Maintaining a fork isn't a
> >simple task, but with supporting users and contributing developers it
> >should be easier.
> >
> >And specially, are MariaDB developers interested in fixing/improving
> >DBD::mysql fork, so Perl could work better with MariaDB servers? At
> >least it would be able to compile against the new MariaDB C-client?
> >

Re: Fork DBD::mysql

[Darren Duncan]

On 2017-08-28 12:00 PM, Alexander Foken wrote:

On 28.08.2017 18:19, Darren Duncan wrote:

While a fork may be the best short term fix, as keeping up with security
issues is important, ...


Not being able to connect to MySQL / MariaDB from Perl is not acceptable. Having
tons of known bugs, especially security-related ones, is as bad. Being forced to
take the long detour through DBD::ODBC, an ODBC driver, and a MySQL / MariaDB
ODBC driver is not pretty, and it won't be faster than the native DBD::mysql
driver.

Indentionally breaking DBD::mysql to drive people away from MySQL / MariaDB wont
work. Instead, people will search for another language that does support
connecting to MySQL / MariaDB, like PHP, Python or Java. And so, they will use
MySQL / MariaDB without Perl.


I agree with what you said, and I said as much myself (quoted above).

The I look at it is that keeping a good quality DBD::mysql is important but that 
it would be conceptually a LEGACY SUPPORT feature.


This is similar to how Perl supports, and should support, talking with any tools 
and systems that people have, so people always have the option to use Perl, even 
when the things they're working with aren't the best choices, its still what 
they have.


And Perl's support for MySQL should remain high quality as possible as long as 
it exists.


But I believe that's mainly a short term solution, and the longer term solution 
is to migrate to better DBMSs.


-- Darren Duncan

Re: Fork DBD::mysql

[David Nicol]

It looks like this fork happened some time ago, and a DBD::maria is now
needed, to keep up. Is that not what it looks like?


-- 
everything has to be just so or the magic won't work

Re: Fork DBD::mysql

[Alexander Foken]

On 28.08.2017 18:19, Darren Duncan wrote:

On 2017-08-28 8:55 AM, p...@cpan.org wrote:

Because of the current situation we in the GoodData company are thinking
about forking DBD::mysql. We use DBI not only with DBD::mysql, but also
with DBD::Pg. The annoying bugs in DBD::mysql still require hacks and
workarounds, while similar bugs were fixed in DBD::Pg years ago. Also,
inability to use the new version of MySQL or MariaDB is a problem. Same
for the open security issues.

I would like to ask, whether somebody else is interested in DBD::mysql
fork? Either as a user or as a developer? Maintaining a fork isn't a
simple task, but with supporting users and contributing developers it
should be easier.


While a fork may be the best short term fix, as keeping up with 
security issues is important, I honestly believe that the best fix is 
to migrate to Postgres as soon as you can.  You already use Pg so the 
experience in your company is there.  I'd say move all your MySQL 
projects to Pg and then you won't have to think about MySQL anymore.  
Its not just about the Perl driver, but the differences in 
quality/features/etc of the DBMSs themselves. -- Darren Duncan


I would really like to second your statement, and I agree that switching 
to Pg would solve a lot of palis problems.


BUT:

MySQL won't go away any time soon. Yes, it is - to be friendly - butt 
ugly, and it should be avoided at almost all costs, but it won't go 
away. Oracle could not kill it, people crated a new and successful fork 
named MariaDB instead of using Pg. Any cheap shared web hoster offers 
MySQL or MariaDB. Tons of legacy apps use MySQL or MariaDB, especially 
if PHP is also around..


Not being able to connect to MySQL / MariaDB from Perl is not 
acceptable. Having tons of known bugs, especially security-related ones, 
is as bad. Being forced to take the long detour through DBD::ODBC, an 
ODBC driver, and a MySQL / MariaDB ODBC driver is not pretty, and it 
won't be faster than the native DBD::mysql driver.


Indentionally breaking DBD::mysql to drive people away from MySQL / 
MariaDB wont work. Instead, people will search for another language that 
does support connecting to MySQL / MariaDB, like PHP, Python or Java. 
And so, they will use MySQL / MariaDB without Perl.


So yes, forking or taking over DBD::mysql developments looks like a good 
idea. I would prefer the latter, because that would really solve 
problems that people using DBD::mysql currently have. Simply updating 
DBD::mysql in the future would fix them, without any need to switch to 
another DBD. We should avoid having more than one database driver for 
each database, except for optional pure-perl implementations like 
DBD::PgPP. That just wastes resources.


Alexander



--
Alexander Foken
mailto:alexan...@foken.de http://www.foken.de/alexander/

Re: Fork DBD::mysql

[Darren Duncan]

On 2017-08-28 8:55 AM, p...@cpan.org wrote:

Because of the current situation we in the GoodData company are thinking
about forking DBD::mysql. We use DBI not only with DBD::mysql, but also
with DBD::Pg. The annoying bugs in DBD::mysql still require hacks and
workarounds, while similar bugs were fixed in DBD::Pg years ago. Also,
inability to use the new version of MySQL or MariaDB is a problem. Same
for the open security issues.

I would like to ask, whether somebody else is interested in DBD::mysql
fork? Either as a user or as a developer? Maintaining a fork isn't a
simple task, but with supporting users and contributing developers it
should be easier.


While a fork may be the best short term fix, as keeping up with security issues 
is important, I honestly believe that the best fix is to migrate to Postgres as 
soon as you can.  You already use Pg so the experience in your company is there. 
 I'd say move all your MySQL projects to Pg and then you won't have to think 
about MySQL anymore.  Its not just about the Perl driver, but the differences in 
quality/features/etc of the DBMSs themselves. -- Darren Duncan

Fork DBD::mysql

[pali]

Hello, 2 months passed since two security problems related to DBD::mysql
were reported, namely CVE-2017-10789 and CVE-2017-10788. Looking at the
DBD::mysql github project page and RT bugtracker, it can be seen that
nothing has happened for 2 months. Some people are asking or waiting for
reported problems to be fixed... Without an answer.

A long discussion was started in April by a group of people who didn't
like the improvements and didn't want to see the bugs fixed in
DBD::mysql driver due to the fact that they probably had old and buggy
legacy code which wouldn't work after DBD::mysql starts fixing bugs.

>From what happened it looks like that this group of people forced
DBD::mysql maintainers to revert all DBD::mysql changes (with all bug
fixes including security ones). And because nothing has happened for 2
months, that looks like fixing those bugs is not planned.

This means just one thing:

  DBD::mysql is dead right now :-(

There are no new commit for 2 months, no evidence of any activity. And
it looks like this is what that group of people wanted. They haven't
written anything, neither any comment about open security issues, nor
any comment that they forced maintainers to revert a security related
bug fix. Probably they don't have to fix their own code and they can use
the last released version of DBD::mysql. Perfect for them, probably a
catastrophe for all others which don't want to use probably-vulnerable
code.

But it also means that it isn't possible to compile the last DBD::mysql
with the new MySQL 8 or new MariaDB versions. More linux distributions
started to pack/bundle their own DBD::mysql patches just because they
need to build DBD::mysql into their repositories with upgraded MariaDB.

I need to say that such situation is not acceptable for *any* future or
new development in Perl which uses either MySQL or MariaDB database.

DBD::mysql has couple of bugs (some are security released) and fully
non-working UTF-8/Unicode support. It means that any internationalized
applications which use MySQL are hard to write in Perl.

Because of the current situation we in the GoodData company are thinking
about forking DBD::mysql. We use DBI not only with DBD::mysql, but also
with DBD::Pg. The annoying bugs in DBD::mysql still require hacks and
workarounds, while similar bugs were fixed in DBD::Pg years ago. Also,
inability to use the new version of MySQL or MariaDB is a problem. Same
for the open security issues.

I would like to ask, whether somebody else is interested in DBD::mysql
fork? Either as a user or as a developer? Maintaining a fork isn't a
simple task, but with supporting users and contributing developers it
should be easier.

And specially, are MariaDB developers interested in fixing/improving
DBD::mysql fork, so Perl could work better with MariaDB servers? At
least it would be able to compile against the new MariaDB C-client?