Re: Doc: fix the rewrite condition when executing ALTER TABLE ADD COLUMN
От | jian he |
---|---|
Тема | Re: Doc: fix the rewrite condition when executing ALTER TABLE ADD COLUMN |
Дата | |
Msg-id | CACJufxGLcbFVS8xAC9OBPn0U_2YjKOiHLdmBrtds1j=5eA5MMA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Doc: fix the rewrite condition when executing ALTER TABLE ADD COLUMN (Álvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Doc: fix the rewrite condition when executing ALTER TABLE ADD COLUMN
|
Список | pgsql-hackers |
hi. https://git.postgresql.org/cgit/postgresql.git/commit/?id=11bd8318602fc2282a6201f714c15461dc2009c6 + 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. As an exception, when changing the type of an existing column, + if the <literal>USING</literal> clause does not change the column + contents and the old type is either binary coercible to the new type + or an unconstrained domain over the new type, a table rewrite is not + needed. In the current development branch, virtual generated columns still do not support the domain. you can not change the generation expression if it contains a check constraint on it. so virtual generated columns don't need rewriting. IMHO, the committed doc description didn't mention this exception. we need some text to cover this exception?
В списке pgsql-hackers по дате отправления: