Re: Document NULL

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(at)eisentraut(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Document NULL
Date: 2024-12-10 18:52:53
Message-ID: 5fbbebb78a9e5ecea8adbbc1ba720dd0ca6d5205.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-12-10 19:53:45 Re: Assert failure on running a completed portal again
Previous Message Robert Haas 2024-12-10 18:48:54 Re: Assert failure on running a completed portal again