Re: Document NULL

Thank you for taking the time to look this over.

On Wed, Nov 20, 2024 at 3:19 AM jian he <jian(dot)universality(at)gmail(dot)com> wrote:

> On Sat, Jun 29, 2024 at 4:40 AM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> >
> > The attached are complete and ready for review. I did some file
> structure reformatting at the end and left that as the second patch. The
> first contains all of the content.
> >
> > I'm adding this to the commitfest.
> >
> > Thanks!
> >
> > David J.
>
> in doc/src/sgml/nullvalues.sgml
> can we mention
> \pset null NULL
> command, then NULL means this value is NULL.
>
> you can also see doc/src/sgml/func.sgml
> (The above example can be copied-and-pasted
> into <application>psql</application> to set things up for the following
> examples.
>

Good idea. I'll see how it plays out.

> -------------------------------------------------------------
> in doc/src/sgml/nullvalues.sgml
> see the attached for one example output
>
> in doc/src/sgml/nullvalues.sgml we have
> one_whitespace<programlisting>
> two_whitespace<programlisting>
> three_whitespace<programlisting>
> four_whitespace<programlisting>
>
> i think you need zero whitespace for tag <programlisting>. like
> <programlisting>
> </programlisting>
>
> https://tdg.docbook.org/tdg/4.5/programlisting
> says whitespaces are significant.
>

Did you not apply patch 0002? The indentation in 0001 exists because it
was much easier to deal with collapse-all related viewing in my editor. I
removed it in 0002 since the final commit would indeed not be so indented.
The tag itself doesn't actually care but its content does indeed get
undesirably indented if the markup is nested in the typical manner.

> <<>>
> As noted in <xref linkend="json-type-mapping-table"/>, JSON has a null
> value
> that does not get exposed at the SQL level.
> <<>>
> i feel like this sentence is weird. since these two are different things.
>

Yeah, the linked page and this summary/pointer need a bit of work. I don't
like the unexplained "different concept" but probably "not exposed" isn't
much better. As this gets closer to being committable I'll see about
getting this topic cleaned up. Suggestions welcomed.

>
> I think some of the query and query output can be combined into one
> <programlisting>.
> no need one <programlisting> for the query, one <screen> for the output.
>

Trivial to change but having both seems more semantically correct and
easier to read IMO. We don't have a policy document covering this that I'm
aware of, and IIRC both variations presently exist in the documentation.

David J.