On Sat, Jun 29, 2024 at 4:40 AM David G. Johnston <david.g.johnston@gmail.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>
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.
