Re: [HACKERS] CIDR type and functions
От | Tom Ivar Helbekkmo |
---|---|
Тема | Re: [HACKERS] CIDR type and functions |
Дата | |
Msg-id | 86ogrkd3y5.fsf@athene.nhh.no обсуждение исходный текст |
Ответ на | Re: [HACKERS] CIDR type and functions (darcy@druid.net (D'Arcy J.M. Cain)) |
Ответы |
Re: [HACKERS] CIDR type and functions
|
Список | pgsql-hackers |
D'Arcy J.M. Cain: > netmask('192.3.4.5/24::cidr') == 255.255.255.0 > masklen('192.3.4.5/24::cidr') == 24 > host('192.3.4.5/24::cidr') == 192.3.4.5 > network('192.3.4.5/24::cidr') == 192.3.4.0 > broadcast('192.3.4.5/24::cidr') == 192.3.4.255 > and perhaps; > class('192.3.4.5/24::cidr') == C > classnet('192.3.4.5/24::cidr') == 192.3.4 Bruce Momjian: > Yes, we need those. Code them up, and I will add them as standard > types. This is really all contrary to the concept of CIDR notation. While I did end up calling the type INET instead of CIDR (which seemed to be the consensus when the discussion was going on, because INET would be more intuitively understandable by users than CIDR), I still stuck to the behavior that Paul Vixie wanted: CIDR notation and representation. It seemed to me that this was a good compromise, as it gives us a clean, standards-based notation where host addresses are a functioning special case. However, networks, netmasks, broadcast addresses and interface addresses all need to be stored in separate INET values. If what we actually want is what D'Arcy shows above, then we should drop CIDR notation, stop using Paul Vixie's functions for dealing with the same, and change the storage format to include more information, and a different and more flexible input format. Just off the top of my head, 'inet 158.37.96.1 netmask 0xffffff00 broadcast 158.37.96.255' would be a cool input (and output) format to support. :-) D'Arcy J.M. Cain: > OK, I started but I could use a small change to inet_net_ntop.c [...] I have to side with Paul on this one: that file and its companion with the similar name were pulled in from the BIND distribution simply for convenience, so we wouldn't have to insist that people must install BIND from source to be able to install PostgreSQL. We really, really shouldn't change them. If what we want is not what they implement, we should drop them and implement what we want. My vote (surprise! surprise!) goes toward keeping what we've got right now. As Paul says, there's an RFC describing the behavior of the data type as it now stands, and it's not as if it were difficult to do all the other things one might want to do with it. However, adding utility functions to do some of the things D'Arcy suggests sounds good. I would think that they should be defined to take INET parameters and return INET results, and the most useful ones seem to me to be the following three (shown with various inputs): netmask('158.37.96') ==> '255.255.255.0/32' netmask('158.37.96/21') ==> '255.255.248.0/32' broadcast('158.37') ==> '158.37.255.255/32' broadcast('158.37.96') ==> '158.37.96.255/32' broadcast('158.37.96/21') ==> '158.37.103.255/32' network('158.37.96.15') ==> '158.37/16' Note that the last one has to assume the old class A/B/C/D/E stuff. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
В списке pgsql-hackers по дате отправления: