Re: Document NULL

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

> On Fri, May 3, 2024 at 9:00 AM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
> wrote:
>
> > On Fri, May 3, 2024 at 8:44 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)sraoss(dot)co(dot)jp>