Re: CIDR/IP types. Was: [GENERAL] big numbers
От | Paul A Vixie |
---|---|
Тема | Re: CIDR/IP types. Was: [GENERAL] big numbers |
Дата | |
Msg-id | 199809041824.LAA24527@bb.rc.vix.com обсуждение исходный текст |
Ответ на | Re: CIDR/IP types. Was: [GENERAL] big numbers (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-hackers |
> I can take care of putting the code into the main PostgreSQL system, but > I need someone to give me a definitive cidr/ip type that I can > integrate. > > People really want this for 6.4. We are in beta, but we can add this > type IF we can get it integrated within the next week or ten days. > > When do you think you can you look over both versions, and send me one > good version to work with? > > I can take it from there, and Paul and I can work out any bugs in the > code. > > Even if you just say, "Paul's is better, throw out ip_and_mac", that is > all we need. i don't think it's that clear cut. my type is intended for layer 3 applications (IP) where either hosts or networks (or subnets including variable-width subnets) need to be used as keys. the ip_and_mac type is host-only but has an unfortunate bridging between layer 3 and layer 2. in my opinion these are separate types, and since cidr is ready to go in we ought to defer ip_and_mac to 6.5, and refocus it on layer 2 applications. consider an ARP or DHCP table, which maps between layer 3 and layer 2. having a type optimized for layer 3 and a different type optimized for layer 2 creates no ugliness in my mind, and in fact serves the only need i can imagine better than a single multihedral type would do. note that cidr as supplied is capable of holding ipv6, which is also a layer 3 entity. changing the name from CIDR to INET would be ok by me, but making a type which is capable of holding either a layer 3 entity or a layer 2 one would create semantic tension in my mind about it.
В списке pgsql-hackers по дате отправления: