Feedback-ID: ia2694551:Fastmail
Date: Fri, 14 Mar 2025 20:49:13 +0100
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@alvh.no-ip.org>
To: Masahiro Ikeda <ikedamsh@oss.nttdata.com>
Cc: Robert Treat <rob@xzilla.net>, pgsql-hackers@lists.postgresql.org
Subject: Re: Doc: fix the rewrite condition when executing ALTER TABLE ADD
 COLUMN
Message-ID: <202503141949.7lz6ifydmezq@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <dd294b0e70bb7286c8f6aa14a84b377a@oss.nttdata.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202503141949.7lz6ifydmezq%40alvherre.pgsql>
Precedence: bulk

Hello,

I have pushed this patch now, with some tiny changes.  (I am not a
believer of the semicolon added by commit d31e2a495b6f before the word
"and").

Also, I didn't think that changing a column type was sufficiently close
to the restrictions of column addition to belong in the same
enumeration, so the first phrase is now (note the "as will" bit at the
end):

    Adding a column with a volatile <literal>DEFAULT</literal>
    (e.g., <function>clock_timestamp()</function>), a generated column
    (e.g., <literal>GENERATED BY DEFAULT AS IDENTITY</literal>), a domain
    data type with constraints will require the entire table and its
    indexes to be rewritten, as will changing the type of an existing
    column.


Thank you!

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"It takes less than 2 seconds to get to 78% complete; that's a good sign.
A few seconds later it's at 90%, but it seems to have stuck there.  Did
somebody make percentages logarithmic while I wasn't looking?"
                http://smylers.hates-software.com/2005/09/08/1995c749.html