is indeed
necessary, but this step has another advantage which is that somebody else
also understands the code which will help ensuring that DBD::mysql can be
maintained and remain stable.
Kind Regards,
Night Light
On Fri, Nov 10, 2017 at 9:34 AM, <p...@cpan.org> wrote:
> I do not unders
Forking would take away my concerns (thank you all for suggesting that) but
one thing pops into my mind:
A decision to fork a mature module is not a light decision and should only
be considered as a last resort (when ran out of all options).
So far it is all based on the opinion of only one
ures would use the
> > DBD::mysql2 and fix their code to be compatible with its breaking
> changes.
> >
> > I thought this was settled, and takes care of your concerns, so it was
> just
> > a matter of "make it so".
> >
> > (Anyone replying to thi
For the reason of "silence":
I've spoken to other users to hear that they have passively withdrawn from
this discussion as they are not motivated to be part of a release where
concerns about backwards compatibility are ignored. One of the users wrote
earlier (replace the word "sector" with
, Sep 26, 2017 at 12:34 PM, demerphq <demer...@gmail.com> wrote:
> On 26 September 2017 at 12:15, Night Light <nightligh...@gmail.com> wrote:
> > The corruption is caused by the fact that the data type of a BLOB can
> not be
> > recognized and is therefore UTF8 encoded l
,$content,SQL_BLOB);
$sth->bind_param(3,$first_name,SQL_VARCHAR);
$sth->execute();
On Tue, Sep 26, 2017 at 11:55 AM, demerphq <demer...@gmail.com> wrote:
> On 19 September 2017 at 14:46, Night Light <nightligh...@gmail.com> wrote:
> > Dear Perl gurus,
> >
&g
Dear Perl gurus,
This is my first post. I'm using Perl with great joy, and I'd like to
express my gratitude for all you are doing to keep Perl stable and fun to
use.
I'd like to ask to object to re-releasing this version and discuss on how
to make 4.043 backwards compatible instead.
This change
