The documentation for (==.), (/=.), (==?) and (/=?) is kind of confusing, or contradictory. The first two functions state that the latter two functions are identical to the comparable SQL operator, but then the latter two functions state that they only return bools, which isnt identical to the comparable SQL operator. More importantly, they don't actually state how the null cases are handled. Looking at the source code it looks like both call to coalesce, and so would return False in the case that either argument is null, so that should probably be stated more clearly.
The ? postfixed operators for DBOrd have an opposite issue, where they state that they return null if either argument is null, but don't have the right type to actually return that, also calling to coalesce. It makes me wonder if the ? postfix is supposed to be mnemonic for null cascading behaviour, and was supposed to be consistent for both DBEq and DBOrd, as the documentation for (==.) seems to imply, or is supposed to be mnemonic for returning False on any null, as the source code would imply, or if there isn't really supposed to be any consistency. But even in the latter case, it's really not clear what the desired behaviour for any of these functions actually was, given the inconsistency in the documentation of (==.) vs (==?) and the inconsistency in the documentation vs. source code for functions like (<?).
I feel like null cascading behaviour is more desirable in both cases, since you can always call cascade after the fact anyway, though I'm honestly just curious what the intent was in the first place. None of this is pressing for me personally, I just happened to notice that the type for (<?) wasn't consistent with its documentation, but the source was consistent with (==?), but which wasn't consistent with (==.)'s documentation, and just ended up being left confused.
The documentation for
(==.),(/=.),(==?)and(/=?)is kind of confusing, or contradictory. The first two functions state that the latter two functions are identical to the comparable SQL operator, but then the latter two functions state that they only return bools, which isnt identical to the comparable SQL operator. More importantly, they don't actually state how the null cases are handled. Looking at the source code it looks like both call tocoalesce, and so would returnFalsein the case that either argument is null, so that should probably be stated more clearly.The
?postfixed operators forDBOrdhave an opposite issue, where they state that they return null if either argument is null, but don't have the right type to actually return that, also calling tocoalesce. It makes me wonder if the?postfix is supposed to be mnemonic for null cascading behaviour, and was supposed to be consistent for bothDBEqandDBOrd, as the documentation for(==.)seems to imply, or is supposed to be mnemonic for returningFalseon any null, as the source code would imply, or if there isn't really supposed to be any consistency. But even in the latter case, it's really not clear what the desired behaviour for any of these functions actually was, given the inconsistency in the documentation of(==.)vs(==?)and the inconsistency in the documentation vs. source code for functions like(<?).I feel like null cascading behaviour is more desirable in both cases, since you can always call
cascadeafter the fact anyway, though I'm honestly just curious what the intent was in the first place. None of this is pressing for me personally, I just happened to notice that the type for(<?)wasn't consistent with its documentation, but the source was consistent with(==?), but which wasn't consistent with(==.)'s documentation, and just ended up being left confused.