Re: Document NULL - Mailing list pgsql-hackers

From Marcos Pegoraro
Subject Re: Document NULL
Date
Msg-id CAB-JLwYaCbrN6-76apM-z3D7qKPatRk1CR2rEFdE4yFVo5MjHQ@mail.gmail.com
Whole thread Raw
In response to Re: Document NULL  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
Em sex., 30 de jan. de 2026 às 22:23, David G. Johnston <david.g.johnston@gmail.com> escreveu:
Squashed v13 with that change (also removed the word 'typed') attached.

I think we could split the first <programlisting> into two parts:
- CREATE/INSERT statements
- Exclusive PSQL commands. Then here we could explain that NULL will be 
displayed depending on the client program used.

<para>
  The following <literal>CREATE TABLE</literal> and <literal>INSERT</literal>
  SQL commands can be executed in any SQL client to create and populate
  the persistent table used in the examples below.  
</para>

<programlisting>
CREATE TABLE null_examples ( ... );
INSERT INTO null_examples
</programlisting>

 <para>
The <literal>\pset</literal> commands require the use of <application>psql</application>
  as the client program; they make the resulting output a bit easier to read and do not
  impact any behaviors described herein.  If you do not use <application>psql</application>
 to execute the commands, resulting NULL values may appear as <NULL>, [Null], or any other variation.
</para>

<programlisting>
-- This makes null values print as "Null" in the output instead of an empty string.
-- Note: SQL text output uses "NULL" and JSON text output uses "null"
\pset null Null

-- These cause boolean values to print as true/false instead of t/f.
\pset display_true true
\pset display_false false

-- Removes the row count footer that prints by default.
\pset footer off
</programlisting>

<para>
The examples also omit any transactional command output when
  transactions are used.  Instead, each transaction gets its own display block.
  Some outputs have <literal>/* ... */</literal> comments and newlines
  manually added for clarity.
</para>

regards
Marcos

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Is there value in having optimizer stats for joins/foreignkeys?
Next
From: Tom Lane
Date:
Subject: Re: Decoupling our alignment assumptions about int64 and double