Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boolean comparison operators have confusing/incorrect documentation #310

Open
abigailalice opened this issue Mar 5, 2024 · 0 comments
Open

Comments

@abigailalice
Copy link
Contributor

abigailalice commented Mar 5, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants