On Mon, May 30, 2022 at 4:59 PM Rowan Tommins <rowan.coll...@gmail.com> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
