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

On 2025-01-07 06:27, Robert Treat wrote:
> On Mon, Jan 6, 2025 at 3:18 AM Masahiro Ikeda 
> <ikedamsh@oss.nttdata.com> wrote:
>> 
>> On 2025-01-03 01:25, Robert Treat wrote:
>> > On Tue, Dec 3, 2024 at 3:13 AM Masahiro Ikeda
>> > <ikedamsh@oss.nttdata.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.

OK, thanks for your comments.

Regards,
-- 
Masahiro Ikeda
NTT DATA CORPORATION