On Sat, 11 May 2024 08:33:27 -0700 "David G. Johnston" <david.g.johns...@gmail.com> wrote:
> On Fri, May 3, 2024 at 9:00 AM David G. Johnston <david.g.johns...@gmail.com> > wrote: > > > On Fri, May 3, 2024 at 8:44 AM Tom Lane <t...@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 <nag...@sraoss.co.jp>
