|
1 | | -PostgreSQL type extensions for IP and MAC addresses. |
2 | | ---------------------------------------------------- |
3 | | - |
4 | | -$Id: README,v 1.2 1998/02/14 17:58:03 scrappy Exp $ |
5 | | - |
6 | | -I needed to record IP and MAC level ethernet addresses in a data |
7 | | -base, and I really didn't want to store them as plain strings, with |
8 | | -no enforced error checking, so I put together the accompanying code |
9 | | -as my first experiment with adding a data type to PostgreSQL. I |
10 | | -then thought that this might be useful to others, both directly and |
11 | | -as a very simple example of how to do this sort of thing, so here |
12 | | -it is, in the hope that it will be useful. |
13 | | - |
14 | | -IP addresses are implemented as a 6 byte struct (this may be 1 byte |
15 | | -more than is useful, but I figured that since it has to be at least 5, |
16 | | -it might as well be an even number of bytes) that contains the four |
17 | | -byte address and a mask width. The external representation of an IP |
18 | | -address looks like '158.37.96.15/32' (or just '158.37.96.15', which is |
19 | | -understood to mean the same thing). This address happens to be part |
20 | | -of a subnet where I work; '158.37.96.0/24', which itself is a part of |
21 | | -the larger subnet allocated to our site, which is '158.37.96.0/21', |
22 | | -which again, if you go by the old book, is part of the class "B" net |
23 | | -called '158.37.0.0/16'. |
24 | | - |
25 | | -Input and output functions are supplied, along with the "normal" <, |
26 | | -<=, =, >=, > and <> operators, which all do what you expect. In |
27 | | -addition, there is a function to check whether a given address is a |
28 | | -member of a given subnet: ipaddr_in_net(addr, net), and functions to |
29 | | -return the netmask and the broadcast address of a given network: |
30 | | -ipaddr_mask(net) and ipaddr_bcast(net). |
31 | | - |
32 | | -MAC level ethernet addresses are implemented as a 6 byte struct that |
33 | | -contains the address as unsigned chars. Several input forms are |
34 | | -accepted; the following are all the same address: '08002b:010203', |
35 | | -'08002b-010203', '0800.2b01.0203', '08-00-2b-01-02-03' and |
36 | | -'08:00:2b:01:02:03'. Upper and lower case is accepted for the digits |
37 | | -'a' through 'f'. Output is always in the latter of the given forms. |
38 | | - |
39 | | -As with IP addresses, input and output functions are supplied as well |
40 | | -as the "normal" operators, which do what you expect. As an extra |
41 | | -feature, a function macaddr_manuf() is defined, which returns the name |
42 | | -of the manufacturer as a string. This is currently held in a |
43 | | -hard-coded struct internal to the C module -- it might be smarter to |
44 | | -put this information into an actual data base table, and look up the |
45 | | -manufacturer there. (Another TODO, for both new data types, is to |
46 | | -interface them to indices. If anyone can explain this to me in a way |
47 | | -that is easier to understand than the current documentation, I would |
48 | | -be most grateful!) |
49 | | - |
50 | | -I don't know what changes are needed to the Makefile for other systems |
51 | | -than the one I'm running (NetBSD 1.3), but anyway: to install on a BSD |
52 | | -system: fix the path names in the SQL files and the Makefile if you |
53 | | -need to, then make, make install, slurp the SQL files into psql or |
54 | | -whatever, and you're off. Enjoy! |
55 | | - |
56 | | -Bergen, Norway, 1998-01-31, Tom Ivar Helbekkmo (tih@Hamartun.Priv.NO). |
| 1 | + |
| 2 | +This directory contain 2 new classes - macaddr to store mac addresses |
| 3 | +written by (Bergen, Norway, 1998-01-31, Tom Ivar Helbekkmo |
| 4 | +(tih@Hamartun.Priv.NO)), and ipaddr type and ipaddr_ops operator class, |
| 5 | +rewritten by me (alex@relcom.EU.net, Aleksei Roudnev, Moscow, Russia, |
| 6 | +25.05.98) and written first by Bergen. |
| 7 | + |
| 8 | +To see the description of macaddr type, read README.ORIG file. |
| 9 | +To see the description of ipaddr type, read ipaddr.html file. |
| 10 | + ^^^^^^^^^^^ |
| 11 | + |
| 12 | +This ipaddr type differ slightly from the original one. First, if you |
| 13 | +input '193.124.23.0' it sets /24 prefix instead of /32 (this is in |
| 14 | +accordance to CISCO's notification and our internal data bases and |
| 15 | +records); if you input '0.0.0.0' it's '0.0.0.0/0' (default) but not NULL |
| 16 | +or NOADDR value. |
| 17 | + |
| 18 | +Then, you can store ADDRESS/PREFIX pair, even if ADDRESS is not the |
| 19 | +subnet address (for example, you can store interface address and mask at |
| 20 | +the single attribute). This allow us to determine, for example, which |
| 21 | +interfaces/routers are accessible by connected network for our interface |
| 22 | +(select * from database where '193.124.23.4' @ interface_address); |
| 23 | + |
| 24 | +Then, it have been written a few new functions and a few operators |
| 25 | +(addr1 @ addr - TRUE if addr1 is the part of subnet addr2); |
| 26 | +'ipaddr_print' function allow you to convert address to any form you |
| 27 | +want; and so on. |
| 28 | + |
| 29 | +And then, I add ipi.sql setup script and test1.sql + test2.sql test |
| 30 | +scripts to allow and test indexing by this new class. |
| 31 | + |
| 32 | +This ipaddr type/opclass are used for our internal IP ROUTING and |
| 33 | +ACCOUNTING data base, and I hope it shpuld be usefull for more people. |
| 34 | + |
| 35 | +For those who like crazy tasks, I propose to realise 'RTREE' indexing |
| 36 | +method to allow effectively use '@' operation for the binding statistic |
| 37 | +records to the customers etc networks. Note 'ipaddr' type can be written |
| 38 | +as 'start,end' coordination pair and it's possible to define all '<<, |
| 39 | +&<, @@, etc graphical operators over this type. |
| 40 | + |
| 41 | + |
| 42 | +25.05.1998, Aleksei Roudnev, alex@relcom.EU.net, Relcom, Moscow, Russia. /+7-095-194-1995. |
| 43 | +========================================================================================== |
0 commit comments