Re: Document NULL - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Document NULL
Date
Msg-id CAKFQuwYq3S_0dj-J4VdM3zV6NBzGReQr3bc1TxQX4OsgQXZaTQ@mail.gmail.com
Whole thread Raw
In response to Re: Document NULL  (Marcos Pegoraro <marcos@f10.com.br>)
List pgsql-hackers
On Wed, Dec 11, 2024 at 8:09 AM Marcos Pegoraro <marcos@f10.com.br> wrote:
Em ter., 10 de dez. de 2024 às 20:00, David G. Johnston <david.g.johnston@gmail.com> escreveu:
 
When I finalize the examples I'm probably going to \pset null <NULL>.
Yes, much better than an empty space in the examples, but you need to show what PSET you did, maybe 
    <literal>\pset null</literal> meta-command</link> to specify the textual output of null values
    it encounters in query results. To get same results as you are seeing on this page, do "\pset null <NULL>"

Yes, I will be doing this in some form.  My indecision at the moment is that this ideally belongs in the preamble material for the section but wants the reader to have seen the usage output sub-section.


typo in func.sgml
   <link linkend="nullvalues">three-valued</link> typed
   results (true, false, or null).
should remove that comma, right ?
   results (true, false or null).

I include the Oxford commas unless I'm forbidden to.  There isn't any forbiddance here that I am aware of.  But now I'm questioning whether it should read "true, false, and null" instead of "true, false, or null"...though I'm confident that any of the four options is going to be understood by the reader and this is basically purely stylistic in an area we haven't codified.  Any specific arguments or prior-art to consider for choosing one over the others?
 

Would be good to mention on nullvalues-json section that nulls on JSON values are case sensitive, so NULL or Null won't work



Agreed.

David J.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Controlling the usage of a user-defined cast
Next
From: Tom Lane
Date:
Subject: Re: Add Postgres module info