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

From: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>
Cc: Robert Treat <rob(at)xzilla(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Doc: fix the rewrite condition when executing ALTER TABLE ADD COLUMN
Date: 2025-03-14 19:49:13
Message-ID: 202503141949.7lz6ifydmezq@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-03-14 19:58:43 Re: AIO v2.5
Previous Message Andres Freund 2025-03-14 19:43:15 Re: AIO v2.5