Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
Date
Msg-id 49AFD7AE.EE98.0025.0@wicourts.gov
Whole thread Raw
In response to Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite  (Jaime Casanova <jcasanov@systemguards.com.ec>)
Responses Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite  (Jaime Casanova <jcasanov@systemguards.com.ec>)
List 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 by date:

Previous
From: André Volpato
Date:
Subject: Re: cbrt() broken in AIX
Next
From: André Volpato
Date:
Subject: Re: cbrt() broken in AIX