Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
От | Kevin Grittner |
---|---|
Тема | Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite |
Дата | |
Msg-id | 49AFD7AE.EE98.0025.0@wicourts.gov обсуждение исходный текст |
Ответ на | Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite (Jaime Casanova <jcasanov@systemguards.com.ec>) |
Ответы |
Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR
column should not induce a table rewrite
|
Список | pgsql-hackers |
>>> Jaime Casanova <jcasanov@systemguards.com.ec> wrote: > ALTER TABLE ... TYPE does cause a table rewrite even if new_type = > old_type, and that is actually useful... > for example when you add a fillfactor to an existing table that > fillfactor will not affect the existing data until you rewrite the > table and a convenient way is exactly using ALTER TABLE ... TYPE. I find that to be exactly as useful as it would be to have a table rewrite if I added a new null-capable column, and somewhat less useful than it would be have a table rewrite on dropping a column. Maintaining the function of this clever trick should not be the basis of imposing a burden on relatively common maintenance operations. > now, back to the problem... is not easier to define a column as TEXT > and to put a check to constraint the length? if you wanna change the > constraint that will be almost free Thanks for the interesting suggestion. I'm not sure I'd want to go there for various reasons; but even if I wanted to go that route, how would I modify that constraint without causing the whole table to be scanned for compliance? -Kevin
В списке pgsql-hackers по дате отправления: