Re: Smartest way to resize a column? - Mailing list pgsql-general

From Phoenix Kiula
Subject Re: Smartest way to resize a column?
Date
Msg-id e373d31e0902030410t26d42a4bv90142e4797ecc64c@mail.gmail.com
Whole thread Raw
In response to Re: Smartest way to resize a column?  (Alban Hertroys <dalroi@solfertje.student.utwente.nl>)
List pgsql-general
On Tue, Feb 3, 2009 at 3:33 PM, Alban Hertroys
<dalroi@solfertje.student.utwente.nl> wrote:
> On Feb 3, 2009, at 5:21 AM, Phoenix Kiula wrote:
>
>> On Mon, Jan 12, 2009 at 1:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> .....<snip>....
>>
>>> regression=# update pg_attribute set atttypmod = 35+4 where attrelid =
>>> 't1'::regclass and attname = 'f1';
>>> UPDATE 1
>>> regression=# \d t1
>>>           Table "public.t1"
>>> Column |         Type          | Modifiers
>>> --------+-----------------------+-----------
>>> f1     | character varying(35) |
>>>
>>> (Why the +4 you ask?  It's historical :-()
>>>
>>
>>
>>
>> Tom, this has worked, and a "\d TABLENAME" shows that the column is
>> varchar(35).
>>
>> But I still have messages in my log saying:
>>
>>  ---
>>  ERROR:  value too long for type character varying(20)
>>  ---
>>
>> Why is this? There are no other varchar(20) columns in my DB at all,
>> no other table. Only this column used to be 20 characters and using
>> your command I changed it to 35. It looks alright, the column also
>> accepts the value, but the error is logged.
>>
>> I'm confused. How to stop the error?
>
>
> You don't happen to have any functions that use varchar(20) in their
> arguments or for local variables? I'm not sure they'd cause the shown error,
> but I expect them to.
>



Nope. We don't have any functions. I don't know what "local variables"
mean. We don't use much PLSQL type stuff. Everything is done in PHP,
so no, we don't have any varchar(20) appearing in PHP code.

pgsql-general by date:

Previous
From: Alex Neth
Date:
Subject: Re: Full text index not being used
Next
From: Oleg Bartunov
Date:
Subject: Re: Full text index not being used