kleptog@svana.org (Martijn van Oosterhout) writes:
> What makes it tricky is that people don't agree on how numbers
> should be formatted.
There is a relevant standard, E.164b, where US/Canadian telnos are
formatted like:
+1.4166734124
It should be quite clear how *any* phone number in those countries
would be formatted, given that example...
>> 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.
Unfortunately, the above represents something of a "lowest common
denominator," which, for those that are exchange/area code-happy, is
woefully insufficient.
Mind you, I'd argue that attempts to use more data are quite likely to
be doomed to failure...
>> 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?
At one time, it was a pretty meaningful determinant of location.
But it is growing increasingly useless, as it is increasingly common
for there to be numerous somewhat-overlapping "area codes" for any
given metropolitan region.
The Toronto region (in Canada, albeit, but under much the same rules)
includes "area codes" 416, 905, and 647.
The Dallas/Fort Worth region includes area codes 214, 972, 817, 469,
and 682.
NYC includes area codes 212, 347, 516, 631, 646, 718, 917.
Attempts to evaluate terribly much based on area codes are
increasingly likely to fail...
--
select 'cbbrowne' || '@' || 'acm.org';
http://cbbrowne.com/info/unix.html
Don't be so open-minded that your brains fall out.