Re: 7.2 changes to varchar truncation - Mailing list pgsql-general

From Andrew Sullivan
Subject Re: 7.2 changes to varchar truncation
Date
Msg-id 20020114175725.R19866@mail.libertyrms.com
Whole thread Raw
In response to Re: 7.2 changes to varchar truncation  ("Ian Harding" <ianh@tpchd.org>)
List pgsql-general
On Mon, Jan 07, 2002 at 10:54:48AM -0800, Ian Harding wrote:
> This brings up an interesting question, is there a reason to specify n?  In other words, what is the downside of
VARCHARcompared to VARCHAR(n)?   

Depends on whether you want to enforce the length.  I belive that the
new behaviour is more SQL-compliant, but someone with access to the
spec might be abe to correct me.

I will have the same problem soon, so I may change all of mine to plain old VARCHAR now if it makes sense...

> >>> "Jeffrey W. Baker" <jwbaker@acm.org> 12/31/01 02:04PM >>>

> If I have to change my datatypes to text or varchar without a limit, I'll
> have to drop and reload my databases (again), about which I plan to have a
> real bad attitude.

AFAIK, 7.2 will require this anyway.  I believe it's part of the
definition of "major release" that it may require a dump and reload.

--
----
Andrew Sullivan                               87 Mowat Avenue
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M6K 3E3
                                         +1 416 646 3304 x110


pgsql-general by date:

Previous
From: "Jeffrey W. Baker"
Date:
Subject: 7.2b4: faster to dump and reload than to vacuum full
Next
From: Stephan Szabo
Date:
Subject: Re: Passing a null value in pl/pgsql