Re: Doc: fix the rewrite condition when executing ALTER TABLE ADD COLUMN

On Mon, Jan 6, 2025 at 3:18 AM Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com> wrote:
>
> On 2025-01-03 01:25, Robert Treat wrote:
> > On Tue, Dec 3, 2024 at 3:13 AM Masahiro Ikeda
> > <ikedamsh(at)oss(dot)nttdata(dot)com> wrote:
> >>
> >> Hi,
> >>
> >> The documentation seems to overlook the rewrite condition
> >> when executing ALTER TABLE ADD COLUMN.
> >>
> >> The current document states that a volatile DEFAULT will
> >> trigger a rewrite of the table and its indexes. However, the
> >> table and its indexes will also be rewritten when an IDENTITY
> >> column is added, or when a column with a domain data type that
> >> has constraints is added.
> >>
> >> What do you think?
> >>
> >
> > We still see a number of people asking (or confused) about table
> > rewrites when adding columns, so I think the initial tip should
> > remain, though I think it can be cleaned up a little.
> >
> > In the second section (alter_table.sgml) I liked the idea of adding
> > these additional examples, though I tweaked the wording a bit to
> > (hopefully) make it a little easier to read.
> >
> > Modified patch attached.
>
> Thanks! It looks good to me with one minor comment.
>
> Is the following intended to remove "However"? It seems that we don't
> need to modify the lines if the initial tip remains.
>
> <para>
> - However, if the default value is volatile (e.g.,
> - <function>clock_timestamp()</function>)
> + If the default value is volatile (e.g.,
> <function>clock_timestamp()</function>)
> each row will need to be updated with the value calculated at the
> time
>

Technically speaking, because we split the tip into two distinct
paragraphs, use of the word however would be considered poor grammar,
though I'll admit I only removed it because it felt superfluous.

Robert Treat
https://xzilla.net