Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55196
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E63BAE7.90208@sugarcrm.com>
References: <1314966424.2150.26.camel@guybrush>
	<4E60F712.4010901@lerdorf.com>
	<4E612BBA.2000509@oracle.com>
	<4E612D70.70606@sugarcrm.com>
	<4E616A8E.8040401@lerdorf.com>
	<4E617B3F.4080105@sugarcrm.com>
	<4E617C9B.1040504@lerdorf.com>
	<4E617E2B.7070507@sugarcrm.com>
	<4E618811.4010703@lerdorf.com>
	<4E630091.4070009@sugarcrm.com>
	<4E634143.3010907@thelounge.net>
	<4E6345D9.4070807@sugarcrm.com>
	<CAEZPtU4DrY58=5JOi9kz=d7TRgWu4NTOd5EDRy0D+9NvmUBYbA@mail.gmail.com>
	<4E635176.9000406@sugarcrm.com>
	<CAEZPtU73xvY7Kiu16Puc0wGs5fgYrK52Re-3tJNk9PRo5thofg@mail.gmail.com>
	<CAEZPtU71ZdB0W=xd==2d-yHOjFWz+0fy7KTiBO+buzhv4KBqwg@mail.gmail.com>
	<4E63BAE7.90208@sugarcrm.com>
Date: Sun, 4 Sep 2011 19:59:39 +0200
Message-ID: <CAEZPtU5_5-qGc5b84UCxucAENS+942ggvaLACLRtaoo9kbvE-g@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Sun, Sep 4, 2011 at 7:52 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> So you're saying breaking BC is OK if only you can find some unaffected
> applications, right?

No, just like what I said for the is_a change, but it was acceptable
for is_a, right? is_a actually broken many (many) apps and codes out
there and it was easily identified, and it was even acceptable in a
patch release. Go figure.

>> There are incimoatibilities too across libmysql versions and across
>> mysql servers, which are actually affecting existing codes.
>
> I don't know of any incompatibilities that change semantics on this level,
> and anyway libmysql is beyond our control, but mysqlnd isn't.

Look at the history for the mysql's bugs, plenty of them, internally
or in userland.

>> I cannot find any code out there relying on this test case and I very
>> much doubt there is any. It is a non issue (unlike the is_a change for
>> example).
>
> Why we're testing for functions that, as you claim, nobody ever uses?

Can you please, and seriously, that's my last attempt, read my answers
and see what we actually test? I never claimed that nobody uses this
behavior but I cannot find any code, app or framework failing with
mysqlnd. Please find one and I will change my mind.

Btw, I have seen many totally pointless tests written for the sake of
having a better code coverage while the code itself makes absolutely
no sense or could even represent something that should not work this
way in the 1st place.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org