Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117838 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 62561 invoked from network); 30 May 2022 13:49:07 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 May 2022 13:49:07 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CAE001801FD for ; Mon, 30 May 2022 08:32:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 30 May 2022 08:32:53 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id h75so13588474ybg.4 for ; Mon, 30 May 2022 08:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=hy0D2F4Fdlf6oTUzAIi52D3+BNUJ/y0Qcqxam6KE5po=; b=HItss42KPJTpAkjp8hVRUCoyxqY9G/ONA7C9SBkALY2ZJj4yUsj6v4ZKxi6R9B3Ja/ roo0blR/HC8UhgOTfJos/bafAgneEhNSdwX4AFf+X3T5jGgq4QIO0HlisFt8oPWveYmZ Fem2wVhl7DIquhGIjuhT3fWwuw+ORLKVDEftne0McveFbeOZDfcz2Jcb3Xw3eEvkTmVB AuMmwZCYX/WPG1xjNKmb/Gg3rJQLoTnJEdv7Uyc5kgWt4DBVZJF/+YWh0uQpvONDN/P0 pJnjcA+U3ayuWOYzYsvocjbzc5yEy+gxrg7Fk6gQtXVeIQvVur8cqInZ4x1agVMU2c3G +JyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=hy0D2F4Fdlf6oTUzAIi52D3+BNUJ/y0Qcqxam6KE5po=; b=UqtWnSFXL3L9JR8dCHG1WroqAfWrQFlqaG1rQVy18OgKCc0Z3lPJb8DjiJt9H/5/da wZX1+8KCWBlXlJztaoqUcgDp8B1cUuyrc43k89IbUmQW0fqkvp/HOzHWlJ5+itci9m0Z SlIGRrzB4RUlDGHmXR7YRhDsGw1+JXxxCts4z8OAT0Q+ZVBZ3KOMQzCOCaJkjpOJK4I3 Nh4PyEX1ZUSP+BEPrqwqNAZVc3iU03aIbRcl0GLLLzhViEyK2TOCpik8KA3tXOuw6yXR 097+6TyWL9V3rTcCFgWOS1opKLZLbX+r5Th+5cQtrUyTKvz+PODxXodd2+xzfazpLn9Z XNbQ== X-Gm-Message-State: AOAM530I08d7OBhhMYdpQSqREq1513lgqPzdJKodedKJWJIG1jvjxNbs Eg/xeM/AqBfR2t+jM2Y/qOxo0S0/0PHpr5sk3LZh34ijoA== X-Google-Smtp-Source: ABdhPJzz2GRqYmpkHVSOjpjLifaBb58TMvZgkmUZm+Gm1HCxzj/z5slAfONIN9g/pPltrjPXDPnqmbHblcfUK7/WOWQ= X-Received: by 2002:a5b:912:0:b0:65c:fbbf:b573 with SMTP id a18-20020a5b0912000000b0065cfbbfb573mr3644590ybq.206.1653924772808; Mon, 30 May 2022 08:32:52 -0700 (PDT) MIME-Version: 1.0 References: <1755E8B5-229B-47B2-BBAF-B5E014F5473D@craigfrancis.co.uk> <1180af01-080f-ee0a-3159-74bf7e0a8aea@gmail.com> <5c455146-aee3-b1d3-f6d4-b19e0408204b@gmail.com> In-Reply-To: <5c455146-aee3-b1d3-f6d4-b19e0408204b@gmail.com> Date: Mon, 30 May 2022 17:32:41 +0200 Message-ID: To: internals@lists.php.net Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] Re: NULL Coercion Consistency From: guilliam.xavier@gmail.com (Guilliam Xavier) On Mon, May 30, 2022 at 4:59 PM Rowan Tommins wrote: > > The actual code in this case ended up in a generic routine that used > isset() to choose which SQL to generate. An empty string would generate > a WHERE clause that matched zero rows, but a null would omit the WHERE > clause entirely, and match *all* rows. So an extra pre-validation on the > string format might be useful for debugging, but wouldn't result in > materially different results. Maybe the routine could use e.g. array_key_exists() rather than isset()? (anyway, sometimes you *actually* want isset() null behavior, or use a null default for a parameter as a "not passed" argument...) > That's actually an interesting observation. It's probably quite common > to treat empty strings as null when going from input to storage; and to > treat null as empty string when retrieving again. Importantly, databases > generally *don't* treat them as equivalent, Yeah, I only know Oracle to do something as... "clever" as storing an empty VARCHAR '' as NULL (for "optimization" IIRC) -_- > so forgetting that > translation can be a real cause of bugs. I often advocate for string > columns in databases to allow either null or empty string, but not both > (by adding a check constraint), so that such bugs are caught earlier. Same (sometimes you have no choice but allow NULL, e.g. an optional foreign key, but the referenced primary key is not nullable and should generally also reject '') -- Guilliam Xavier