Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70077 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 7854 invoked from network); 10 Nov 2013 09:21:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Nov 2013 09:21:07 -0000 Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender) X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com X-Host-Fingerprint: 173.1.104.101 rproxy2-b-iv.figureone.com Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222) Received: from [173.1.104.101] ([173.1.104.101:64734] helo=rproxy2-b-iv.figureone.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 10/31-02577-3005F725 for ; Sun, 10 Nov 2013 04:21:07 -0500 Received: from localhost ([216.220.114.66]) by rproxy2-b-iv.figureone.com (Brand New Heavy v1.0) with ASMTP id VUF80305 for ; Sun, 10 Nov 2013 01:21:05 -0800 Date: Sun, 10 Nov 2013 04:20:57 -0500 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <127298508.20131110042057@cypressintegrated.com> To: Yasuo Ohgaki In-Reply-To: References: <527DF228.1080108@sugarcrm.com> <416659913.20131110035553@cypressintegrated.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Comparison and conversion inconsistency - need more info From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman) > I think almost all users are not expecting > min(-10000, -1000, -100, NULL, 100, 1000) returns NULL. I expect it. Because, in fact, PHP is not SQL. It is PHP, and it has its own rules that everybody plays by. They aren't SQL rules (where NULLs may either be disregarded, as in aggregates, or quite heavily regarded). The ecosystem of PHP and SQL is, however, one of the fundamental reasons you *must not* make the change you propose. SQL MIN() works across one column within a rowset, while users often desire a similar function that works across columns in a row. As they are unable to do this in pure SQL, they will turn to application code, performing a PHP min() across columns returned from SQL -- columns that quite commonly contain PHP NULL if the DB layer supports it. All this time, they have been getting NULL. You want them to get -10000 for those same rows and not have that affect their application in a big way. Just... no. > Besides, the manual is not explaining this weird behavior at all. Sure it is. -- S.