On Mon, 2024-12-09 at 15:27 -0700, David G. Johnston wrote:
> I have not done this. This is already a large patch and this kind of
> example doesn't seem like our norm. I'm not opposed to more content
> like this but for now would leave considering it as something an
> interested party can propose once this goes in.
Fair enough
Though I think it's a great example and I'd like to find some place to
put it.
>
> <para>
> The presence of null values in the system results in three-valued
> logic.
> In conventional two-valued (binary) logic every outcome is either
> true or false.
> In three-valued logic the concept of unknown, represented using
> the null value, is
> also an outcome. This results in falsifying the common-sense
> notion
> that "p OR NOT p" is always true.
> </para>
Thank you.
I might reword the final sentence as more of an example, like: "Unknown
values can lead to surprising behavior, for instance "NULL OR NOT NULL"
evaluates to the null value."
>
> When executing an aggregate or window function the state tracking
> component
> (which may be initialized to a non-null value, e.g., 0 for the
> count function)
> will remain unchanged even if the underlying processing
> function returns a null value, whether from being defined strict
> or it simply returns a null value upon execution.
Thank you.
> Since count doesn't have an input function to check the only way to
> see zero such rows is if the underlying thing being counted is empty.
While true for COUNT(*), technically that's incorrect for COUNT(x),
which counts the rows for which x is non-null. That doesn't invalidate
your point, though: the initial state is unchanged either way.
Regards,
Jeff Davis
