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

From Matteo Beccati
Subject Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
Date
Msg-id 49AFF412.7030506@beccati.com
Whole thread Raw
In response to Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite  (Guillaume Smet <guillaume.smet@gmail.com>)
Responses Re: Expanding the length of a VARCHAR column should not induce a table rewrite  ("Kevin Grittner" <Kevin.Grittner@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>)
List pgsql-hackers
Guillaume Smet ha scritto:
> On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> The question is how you want to implement this in a data type independent
>> fashion.  You can't assume that increasing the typmod is a noop for all data
>> types.
> 
> Sure. See my previous answer on -hackers (I don't think this
> discussion belong to -bugs) and especially the discussion in the
> archives about Jonas' patch.

I recently had a similar problem when I added some domains to the
application. ALTER TABLE ... TYPE varchar_dom was leading to a full
table rewrite even though the underlying type definition were exactly
the same (i.e. varchar(64)). I can live with it, but I suppose this fix
might be related to the varlen one.


Cheers

-- 
Matteo Beccati

OpenX - http://www.openx.org


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Prepping to break every past release...
Next
From: ohp@pyrenet.fr
Date:
Subject: Re: pg_restore -m failing