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

Поиск
Список
Период
Сортировка
От Jaime Casanova
Тема Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
Дата
Msg-id 3073cc9b0903051126t49db73ady7a46528b06d9658d@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite  (Matteo Beccati <php@beccati.com>)
Ответы Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
Список pgsql-hackers
On Thu, Mar 5, 2009 at 10:47 AM, Matteo Beccati <php@beccati.com> wrote:
> 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.
>

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

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


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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Make SIGHUP less painful if pg_hba.conf is not readable
Следующее
От: Tom Lane
Дата:
Сообщение: Re: building pg_dump doesn't work