Re: Document NULL - Mailing list pgsql-hackers

On Sat, 11 May 2024 08:33:27 -0700
"David G. Johnston" <david.g.johnston@gmail.com> wrote:

> On Fri, May 3, 2024 at 9:00 AM David G. Johnston <david.g.johnston@gmail.com>
> wrote:
> 
> > On Fri, May 3, 2024 at 8:44 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> >> Having said that, I reiterate my proposal that we make it a new
> >>
> > <sect1> under DDL, before 5.2 Default Values which is the first
> >> place in ddl.sgml that assumes you have heard of nulls.
> >
> >
> > I will go with this and remove the "Data Basics" section I wrote, leaving
> > it to be just a discussion about null values.  The tutorial is the only
> > section that really needs unique wording to fit in.  No matter where we
> > decide to place it otherwise the core content will be the same, with maybe
> > a different section preface to tie it in.
> >
> >
> v3 Attached.
> 
> Probably at the 90% complete mark.  Minimal index entries, not as thorough
> a look-about of the existing documentation as I'd like.  Probably some
> wording and style choices to tweak.  Figured better to get feedback now
> before I go into polish mode.  In particular, tweaking and re-running the
> examples.
> 
> Yes, I am aware of my improper indentation for programlisting and screen. I
> wanted to be able to use the code folding features of my editor.  Those can
> be readily un-indented in the final version.
> 
> The changes to func.sgml is basically one change repeated something like 20
> times with tweaks for true/false.  Plus moving the discussion regarding the
> SQL specification into the new null handling section.
> 
> It took me doing this to really understand the difference between row
> constructors and composite typed values, especially since array
> constructors produce array typed values and the constructor is just an
> unimportant implementation option while row constructors introduce
> meaningfully different behaviors when used.
> 
> My plan is to have a v4 out next week, without or without a review of this
> draft, but then the subsequent few weeks will probably be a bit quiet.

+   A null value literal is written as unquoted, case insensitive, NULL.
...(snip)...
+  <programlisting>
+  SELECT
+    NULL,
+    pg_typeof(null),
+    pg_typeof(NuLl::text),
+    cast(null as text);
+  </programlisting>

It may be a trivial thing but I am not sure we need to mention case insensitivity
here, because all keywords and unquoted identifiers are case-insensitive in
PostgreSQL and it is not specific to NULL.

Also, I found the other parts of the documentation use "case-insensitive" in which
words are joined with hyphen, so I wonder it is better to use the same form if we
leave the description.

Regards,
Yugo Nagata

-- 
Yugo NAGATA <nagata@sraoss.co.jp>