Re: User defined types -- Social Security number...

From: Michael Chaney <mdchaney(at)michaelchaney(dot)com>
To: pgsql-sql(at)postgresql(dot)org
Subject: Re: User defined types -- Social Security number...
Date: 2004-03-01 21:12:31
Message-ID: 20040301211231.GA19105@michaelchaney.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

On Sun, Feb 29, 2004 at 11:11:31PM -0500, Christopher Browne wrote:
> The world rejoiced as mdchaney(at)michaelchaney(dot)com (Michael Chaney) wrote:
> > Look, you're thinking way too hard on this. An SSN is a 9-digit number,
> > nothing more. There are some 9-digit numbers which aren't valid SSN's,
> > and you might want to get fancy and create a constraint for that.
> >
> > Regardless, you are making a *major* mistake of confusing data
> > storage with rendering. It is common to *render* an SSN as
> > xxx-xx-xxxx and its cousin the FETID (Federal Employers Tax ID) as
> > xx-xxxxxxx. To store the dashes makes no sense. They're in the
> > same place each time, it's wasted data.
> >
> > Store the SSN as an "integer". When you begin to think about this
> > correctly, the "leading zeros" problem disappears since that is also a
> > *rendering* issue.
>
> Well put.
>
> The one thing that is a bit unfortunate is that 32 bit ints aren't
> quite big enough for this. You need 1 extra digit :-(.

For what? The largest SSN is 999,999,999, a signed 32-bit int goes to
just over 2,000,000,000. Ever hear of a "4GB limit"?

Michael
--
Michael Darrin Chaney
mdchaney(at)michaelchaney(dot)com
http://www.michaelchaney.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Chaney 2004-03-01 21:18:43 Re: User defined types -- Social Security number...
Previous Message Thomas Hallgren 2004-03-01 20:10:47 Re: Server Side PL support

Browse pgsql-sql by date

  From Date Subject
Next Message Louie Kwan 2004-03-01 21:18:15 SYSDATE in PostgreSQL !?
Previous Message Joe Conway 2004-03-01 18:45:36 Re: returning a recordset from PLpg/SQL