Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Re: BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite

From: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
To: Matteo Beccati <php(at)beccati(dot)com>
Cc: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, xuan--2009(dot)03--submitbug--support--postgresql(dot)org(at)baldauf(dot)org, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Re: BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
Date: 2009-03-05 19:26:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
On Thu, Mar 5, 2009 at 10:47 AM, Matteo Beccati <php(at)beccati(dot)com> wrote:
> Guillaume Smet ha scritto:
>> On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut <peter_e(at)gmx(dot)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.

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.

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

Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-03-05 19:37:05
Subject: Re: building pg_dump doesn't work
Previous:From: Magnus HaganderDate: 2009-03-05 19:19:05
Subject: Re: Make SIGHUP less painful if pg_hba.conf is not readable

pgsql-bugs by date

Next:From: Kevin GrittnerDate: 2009-03-05 19:46:22
Subject: Re: Re: [BUGS] BUG #4689: Expanding the length of aVARCHAR column should not induce a table rewrite
Previous:From: Kevin GrittnerDate: 2009-03-05 19:15:26
Subject: Re: Expanding the length of a VARCHAR column should not inducea table rewrite

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group