A few points.
1. clarification of my IRC comment: A quick examination seems to shaw that we use the native getaddrinfo() where it exists, otherwise we use our own, which in turn calls inet_ntoa().
2. ip6 has a well defined standard for abbreviation, and is quite important to have since ip6 addresses would otherwise often be tediously long. I haven't found a comparable standard for abbreviating IP4 addresses. There appears to be a convention relying on behaviour of inet_aton, and perhaps hallowed by history, but by any measure surely brain dead and counter intuitive. Why would a.b.c become a.b.0.c and a.b become a.0.0.b? On Linux it is not even documented. See the email from Paul Vixie cited below for futher gory details, including a citation of rfc1208 that specifies exactly 4 parts for a dotted notation. It's not surprising that he starts one sentence thus: "Now, before you laugh so hard you fall out of your collective seats,".
3. Maybe some people are used to it. In around 15 years of using and administering Unix I haven't tripped over this before, so I suspect it's probably not a huge problem :-)
4. My personal preference would be that if any change is made it would be to insist on an unabbreviated dotted quad for ip4. Alternatively, we need to make sure that whatever we do is consistent. That might not be possible, however, if different platforms or different library calls behave differently.
cheers
andrew
Alex J. Avriette wrote:
So one of the client machines for one of my databases at work resides on 10.128.0.45. I had to enter something in pg_hba.conf for it today, as we're bringing this database up. We have a lot of 10/8 subnets, and I use it at home, so I'm accustomed to just using 10.128.45 for the IP. Strangely, however, postgres refused to acknowledge the host when it connected. I checked it again, and sure enough, the IP was right. It turns out that postgres parses pg_hba.conf in an unexpected way -- it does not accept "abbreviated" ip4 addresses (note that this is common in both ip4 and ip6).
In the manpage for inet_aton, we see:
INTERNET ADDRESSES (IP VERSION 4) Values specified using the `.' notation take one of the following forms:
a.b.c.d a.b.c a.b a
When four parts are specified, each is interpreted as a byte of data and assigned, from left to right, to the four bytes of an Internet address.
Andrew Dunstan on IRC mentioned that the parser is using the native getaddrinfo. I'm not sure if there are any advantages to this; I've said before that I'm really not a C guy.
Paul Vixie had this to say about the convention:
What this man page is trying to tell you is that BSD users have historically said "10.73" rather than "10.0.0.73" because they both worked any place where either worked. This includes DNS primary zone files, by the way.
I am pretty much assuming that the IETF does not want to standardize this BSD practice, and that we ought not to accept ::10.73 as equivilent to the longer ::10.0.0.73, especially given that the degenerate case given in that man page would be ambiguous with respect to ::1234, a valid RFC1884 address specifier whose low order 16 bits are hexadecimal 1234 rather than decimal 1234.
However, that's only _my_ assumption, and some other implementor may
feel differently. In fact some other implementor of RFC 1884 might
decide to just call inet_aton() for parsing that IPv4 "dotted quad",
which is what I almost did.
The original article can be found here:
http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/IPng/1996-06/0037.html
I think it is important that postgres behave as expected when handing it a properly formatted ip4 address. However, I'm aware that many people don't even realize this is a valid address. As such, I won't lose any sleep over it, but I thought I'd mention it, since it surprised me today.
Thoughts?
Alex
-- [EMAIL PROTECTED] Alex J. Avriette, Solaris Frobnosticator "You can get much farther with a kind word and a gun than you can with a kind word alone." - Al Capone
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
