Re: Cases where alter table set type varchar(longer length) still needs table rewrite

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Cases where alter table set type varchar(longer length) still needs table rewrite
Дата
Msg-id 9756.1581963592@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Cases where alter table set type varchar(longer length) stillneeds table rewrite  (Adrian Klaver <adrian.klaver@aklaver.com>)
Список pgsql-general
Adrian Klaver <adrian.klaver@aklaver.com> writes:
> On 2/17/20 7:01 AM, Jeremy Finzel wrote:
>> I'm still not sure why a rebuild of this index would be required, 
>> technically speaking.  But perhaps in any case the docs should have 
>> something to the effect that expression indexes may require rebuild 
>> under specific circumstances?

> [ it is already ]

Yeah.  In principle, we wouldn't need to rebuild the indexes in this
case, since there's no semantic difference between a value sourced
from a varchar(N) column and a varchar(some-other-N) column.  In general,
though, ALTER COLUMN TYPE doesn't know whether that's true; and there
are definitely binary-compatible cases where it *does* matter.
(An example is that coercing integer to OID is allowed without a
table rewrite, but an index rebuild is needed because the sort
order is different.)  So right now, any index mentioning the altered
column has to be rebuilt.

Maybe someday we'll figure out how to do better.  I'm kind of wondering
whether it wouldn't be safe to assume that changes that only change the
typmod and not the type OID don't require index rebuilds.

            regards, tom lane



В списке pgsql-general по дате отправления:

Предыдущее
От: Jeremy Schneider
Дата:
Сообщение: Re: PL/pgSQL question about EXCEPTION clause & corrupt records
Следующее
От: Jeremy Finzel
Дата:
Сообщение: Re: Cases where alter table set type varchar(longer length) stillneeds table rewrite