Re: Document NULL

On Thursday, February 6, 2025, jian he <jian(dot)universality(at)gmail(dot)com> wrote:

> On Fri, Jan 17, 2025 at 6:41 AM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> >
> > Yeah, I did spell check but not a grammar check. These weren't spelling
> errors though. Anyway, good point running the resultant web page through
> chatgpt or grammar-aware program.
> >
> > I still need to put together the example changes in these last couple of
> suggestions. The attached v6 omits those and the indenting - and I've
> consolidated it back into a single patch.
> >
> hi.
>
> <title>Array Elements and IN Bag Members</title>
> google "Bag Members" didn't yield any relevant results.
> there are two appearances of "bag" in doc/src/sgml/nullvalues.sgml.
> I am confused by this word.

Apparently “multiset” is the more common term. I first learned it as bag
which is a synonym.

https://en.m.wikipedia.org/wiki/Multiset

> <sect3 id="nullvalues-usage-tables">
> <title>Null Values in Tables</title>
> <para>
> Whether via the copy method above, or by inserting literal null values,
> most usage concerns for null values results from their presence in a
> table
> column that lacks a <link
> linkend="nullvalues-table-constraints">not-null constraint</link>.
> </para>
> We can simply say that, in a table,
> if a specific column doesn't have a not-null constraint, null value
> can exist in that column.
> or maybe this part is unnecessary, we can remove it.

Will ponder and likely change. The section seems relevant since databases
are all about tables so discussing null in that context seems needed even
if there isn’t that much to say.

>
>
> <para>
> As noted in <xref linkend="json-type-mapping-table"/>, the JSON
> specification's
> null value is assigned its own type unlike in SQL. This introduces
> an inconsistency
> since the JSON null type's value is itself non-null. It is also
> comparable to any
> other JSON type, returning false for equality, and itself,
> returning true for equality.
> But an SQL value of json or jsonb type having a JSON null value is
> considered non-null in SQL.
>
> this part """But an SQL value of json or jsonb type having a JSON null
> value is considered non-null in SQL"""
> is the same as
> "since the JSON null type's value is itself non-null.".

so i think removing this sentence "But an SQL value of json or jsonb
> type having a JSON null value is considered non-null in SQL."
> there is no meaning being lost.
> (i think this is minor issue)

I’ll try to make the whole thing less wordy. But stating the implied fact
that since json treats null like a concrete value SQL must do so also seems
warranted.

>
> <sect2 id="nullvalues-settings">
> <title>Null-Valued Settings</title>
> <para>
> There are none. During initialization all settings are assigned a
> non-null value.
> </para>
> "There are none" kind of comes from nowhere.
> I think you mean "There are no null-valued settings"?

Yeah, my personal style, not the documentation’s, came through there. Will
change.

>
>
> <sect2 id="nullvalues-partitionkeys">
> <title>Null Values in Partition Keys</title>
> <para>
> Presently, PostgreSQL requires that all the columns of a partition
> key be included
>
> here "PostgreSQL" should be decorated as <productname>PostgreSQL</
> productname>.
>

Will fix.

Thanks!

David J.