On Jul 10, 2006, at 11:07 AM, Martijn van Oosterhout wrote:

On Mon, Jul 10, 2006 at 10:33:52AM -0700, Karen Hill wrote:
Hello,

How would one go about creating a US telephone type in the format of
"(555)-555-5555" ?  I am at a loss on how it could be accomplished in
the most correct way possible while not going into the various
different country styles e.g. +01 (555) 555-5555.

How do you mean "styles". The above number is, when printed in standard
international format +15555555555. The number needed to dial
international is not relevent. What makes it tricky is that people
don't agree on how numbers should be formatted.

Is the difficulty of creating a telephone type the reason it is not in
postgresql already?

It wouldn't be hard, it's just not clear what the advantage is over
just having a string and some functions to display the number.

Should the telephone type be able to do something such as:

SELECT * from tableFOO where telephone.areacode = 555;

Maybe, but is that useful? Maybe America is different, but my
experience in NL and AU is that you rarely care about the areacode
anyway, so why would you want to pull it out?

Strong correlation to geographical area - very useful for sales
campaigns or geolocation. Also, free numbers (aka 800 numbers
in the US) have distinctive area codes. Of course, identifying
the area code is easy in the US, but much harder (or even
meaningless) elsewhere. In other bits of the world area codes
allow you to identify mobile numbers.

A general phone number type would have a country, an area
code, a local number and an optional extension. Possibly a
"type" (tel, fax, modem) too, possibly not. Possibly an optional
alternate format, so that you can store 1-800-MY-APPLE, but
also be able to treat it as +18006927753. And probably all the
other weirdnesses in RFC 2806 too. Outputs might be E.164,
RFC 2806 URL or (country-specific) "human-readable".

Doing it "right" would be very complex, and overkill for most
applications. Doing a simplistic
version that only supported something like E.164 or only
supported US formating would be easy - but so application
space specific, why bother? Just use a text field or three.

Cheers,
  Steve

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

Reply via email to