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