Re: Cast char to number

From: Bill Moran <wmoran(at)potentialtech(dot)com>
To: rod(at)iol(dot)ie
Cc: Christine Penner <christine(at)ingenioussoftware(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, jd(at)commandprompt(dot)com, Richard Huxton <dev(at)archonet(dot)com>, Postgres-General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Cast char to number
Date: 2010-02-24 22:03:13
Message-ID: 20100224170313.fce5161b.wmoran@potentialtech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

In response to Raymond O'Donnell <rod(at)iol(dot)ie>:

> On 24/02/2010 21:42, Christine Penner wrote:
> > This is what I did.
> >
> > set all blank columns to '0' because they were causing errors.
> > alter table T alter column a type integer using a::integer
> >
> > That worked perfectly.
>
> Glad you got sorted.
>
> Bill's advice upthread is worth taking on board - if you're in a
> position to do so, make sure that numbers are stored as numbers rather
> than text, and you'll save yourself all sorts of wacky grief.

As an aside, I feel that this is a natural part of software evolution.
No matter how carefully you try to plan, you end up with someone
saying, "this will be a serial number that will contain both numbers
and letters" ... so you make it a text type field. Then, a year later
you find out that the serial number is really just a number, and you
actually want to be able to do math on it because you can find out
the year the part was designed by dividing by 1000 or something.

You make the best decisions you can based on the available information.
If you get it wrong, there's always ALTER TABLE :)

--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2010-02-24 22:10:06 Re: Curious plperl behavior
Previous Message Richard Huxton 2010-02-24 21:47:01 Re: Curious plperl behavior