head	1.5;
access;
symbols
	release-6-3:1.2;
locks; strict;
comment	@# @;


1.5
date	98.10.03.05.40.21;	author momjian;	state dead;
branches;
next	1.4;

1.4
date	98.06.16.05.35.10;	author momjian;	state Exp;
branches;
next	1.3;

1.3
date	98.06.16.04.34.29;	author momjian;	state Exp;
branches;
next	1.2;

1.2
date	98.02.14.17.58.03;	author scrappy;	state Exp;
branches;
next	1.1;

1.1
date	98.01.25.07.10.48;	author scrappy;	state Exp;
branches;
next	;


desc
@@


1.5
log
@Integrate new IP type from Tom Ivar Helbekkmo.
@
text
@
This directory contain 2 new classes - macaddr to store mac addresses
written by (Bergen, Norway, 1998-01-31, Tom Ivar Helbekkmo
(tih@@Hamartun.Priv.NO)), and ipaddr type and ipaddr_ops operator class,
rewritten by me (alex@@relcom.EU.net, Aleksei Roudnev, Moscow, Russia,
25.05.98) and written first by Bergen.

To see the description of macaddr type, read README.ORIG file. To see
the description of ipaddr type, read ipaddr.html file.
					    ^^^^^^^^^^^

This ipaddr type differ slightly from the original one. First, if you
input '193.124.23.0' it sets /24 prefix instead of /32 (this is in
accordance to CISCO's notification and our internal data bases and
records); if you input '0.0.0.0' it's '0.0.0.0/0' (default) but not NULL
or NOADDR value.

Then, you can store ADDRESS/PREFIX pair, even if ADDRESS is not the
subnet address (for example, you can store interface address and mask at
the single attribute). This allow us to determine, for example, which
interfaces/routers are accessible by connected network for our interface
(select * from database where '193.124.23.4' @@ interface_address);

Then, it have been written a few new functions and a few operators
(addr1 @@ addr - TRUE if addr1 is the part of subnet addr2);
'ipaddr_print' function allow you to convert address to any form you
want; and so on.

And then, I add ipi.sql setup script and test1.sql + test2.sql test
scripts to allow and test indexing by this new class.

This ipaddr type/opclass are used for our internal IP ROUTING and
ACCOUNTING data base, and I hope it shpuld be usefull for more people.

For those who like crazy tasks, I propose to realise 'RTREE' indexing
method to allow effectively use '@@' operation for the binding statistic
records to the customers etc networks. Note 'ipaddr' type can be written
as 'start,end' coordination pair and it's possible to define all '<<,
&<, @@@@, etc graphical operators over this type.


25.05.1998, Aleksei Roudnev, alex@@relcom.EU.net, Relcom, Moscow, Russia. /+7-095-194-1995.
==========================================================================================
@


1.4
log
@try again
@
text
@@


1.3
log
@I investigated carefully POSTGRES data base (in idea to use it for
our internal IP routing data base, and because  I have participated
in Ingres development here in Russia in RUBIN/DEMOS project -
through it was not freeware work - and it was very interesting for
me too see such good freeware data base as PostgreSQL), and I
modified 'ipaddr' data type library in accordance to our requests
and to allow SQL do indexing over ipaddr objects.

You can read description at 'http://relcom.EU.net/ipaddr.html' and
get sources at 'http://relcom.EU.net/ip_class.tar.gz'. It contains
sources, sql scripts for incorporating new data type into postgres
(including ipaddr_ops operator class incorporation) and 20,000
records based data test for the indexing.

I am not sure if it's proper mail list for this information, and
if it's interesting for anyone except me to get full-functional
ipaddress class. I am ready to make all modifications, bug fixing
and documentation for this data class if it's nessesary for it's
contribution to the Postgres data base.

Anyway, all my work was based at original 'ip&mac data type'
contribution, written by Tom Ivar Helbekkmo.

Be free to write me any questions or requests about this work.
==============================================================

Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095)
194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10,
N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28
(Fax)
@
text
@d8 2
a9 2
To see the description of macaddr type, read README.ORIG file.
To see the description of ipaddr type, read ipaddr.html file.
@


1.2
log
@I'm including an update to my user defined IP and MAC address type
implementation that's in contrib/ip_and_mac/.  This one works right
with 6.3, avoids the problems I ran into earlier with LIKE, and
includes a bit of extra functionality.

From: Tom I Helbekkmo <tih@@Hamartun.Priv.NO>
@
text
@a0 2
PostgreSQL type extensions for IP and MAC addresses.
---------------------------------------------------
d2 38
a39 1
$Id: README,v 1.1 1998/02/01 11:57:21 postgres Exp $
a40 49
I needed to record IP and MAC level ethernet addresses in a data
base, and I really didn't want to store them as plain strings, with
no enforced error checking, so I put together the accompanying code
as my first experiment with adding a data type to PostgreSQL.  I
then thought that this might be useful to others, both directly and
as a very simple example of how to do this sort of thing, so here
it is, in the hope that it will be useful.

IP addresses are implemented as a 6 byte struct (this may be 1 byte
more than is useful, but I figured that since it has to be at least 5,
it might as well be an even number of bytes) that contains the four
byte address and a mask width.  The external representation of an IP
address looks like '158.37.96.15/32' (or just '158.37.96.15', which is
understood to mean the same thing).  This address happens to be part
of a subnet where I work; '158.37.96.0/24', which itself is a part of
the larger subnet allocated to our site, which is '158.37.96.0/21',
which again, if you go by the old book, is part of the class "B" net
called '158.37.0.0/16'.

Input and output functions are supplied, along with the "normal" <,
<=, =, >=, > and <> operators, which all do what you expect.  In
addition, there is a function to check whether a given address is a
member of a given subnet: ipaddr_in_net(addr, net), and functions to
return the netmask and the broadcast address of a given network:
ipaddr_mask(net) and ipaddr_bcast(net).

MAC level ethernet addresses are implemented as a 6 byte struct that
contains the address as unsigned chars.  Several input forms are
accepted; the following are all the same address: '08002b:010203',
'08002b-010203', '0800.2b01.0203', '08-00-2b-01-02-03' and
'08:00:2b:01:02:03'.  Upper and lower case is accepted for the digits
'a' through 'f'.  Output is always in the latter of the given forms.

As with IP addresses, input and output functions are supplied as well
as the "normal" operators, which do what you expect.  As an extra
feature, a function macaddr_manuf() is defined, which returns the name
of the manufacturer as a string.  This is currently held in a
hard-coded struct internal to the C module -- it might be smarter to
put this information into an actual data base table, and look up the
manufacturer there.  (Another TODO, for both new data types, is to
interface them to indices.  If anyone can explain this to me in a way
that is easier to understand than the current documentation, I would
be most grateful!)

I don't know what changes are needed to the Makefile for other systems
than the one I'm running (NetBSD 1.3), but anyway: to install on a BSD
system: fix the path names in the SQL files and the Makefile if you
need to, then make, make install, slurp the SQL files into psql or
whatever, and you're off.  Enjoy!
d42 2
a43 1
Bergen, Norway, 1998-01-31, Tom Ivar Helbekkmo (tih@@Hamartun.Priv.NO).
@


1.1
log
@From: Tom I Helbekkmo <tih@@Hamartun.Priv.NO>

PostgreSQL type extensions for IP and MAC addresses.

I needed to record IP and MAC level ethernet addresses in a data
base, and I really didn't want to store them as plain strings, with
no enforced error checking, so I put together the accompanying code
as my first experiment with adding a data type to PostgreSQL.  I
then thought that this might be useful to others, both directly and
as a very simple example of how to do this sort of thing, so here
it is, in the hope that it will be useful.
@
text
@d4 2
d14 1
a14 1
IP addresses are implemented as an 8 byte struct (this may well be
d16 8
a23 7
it might as well round well) that contains the four bytes of address
and a mask width.  Thus, a node address looks like '158.37.96.15/32'
(or just '158.37.96.15', which is understood to mean the same thing).
This address happens to be part of a subnet where I work;
'158.37.96.0/24', which itself is a part of the larger subnet
allocated to our institution, which is '158.37.96.0/21', which again,
if you go by the book, is part of the class "B" net '158.37.0.0/16'.
d26 15
a40 21
<=, =, >=, > and <> operators, which all do what you expect, and the
similarity operator ~~, which checks whether two given addresses are
either the same, or, failing that, whether one is a subnet
specification and the other an address (or a smaller subnet) within
that.  Good for picking out records with addresses in a given subnet:
note that '158.37.96.0/21' spans '158.37.96.0' to '158.37.103.255',
which is not all that easily handled in its external representation.

MAC level ethernet addresses are also implemented as an 8 byte struct
(I wish I knew what alignment needs are actually present -- I'm just
not taking any chances here) that contains the address as unsigned
chars.  Several input forms are accepted: the following are all the
same address: '08002b:010203', '08002b-010203', '0800.2b01.0203',
'08-00-2b-01-02-03' and '08:00:2b:01:02:03'.  Upper and lower case is
accepted for the digits 'a' through 'f'.  Output is always in the
latter of the given forms.

Input and output functions are supplied, along with the = and <>
operators, which do what you expect, and the similarity operator ~~,
which checks whether two given addresses belong to hardware from the
same manufacturer (first three bytes the same, that is).  As an extra
d42 12
a53 4
of the manufacturer as a string.

To install: fix the path names in the SQL files and the Makefile if
you need to, then make, make install, slurp the SQL files into psql or
d56 1
a56 1
Bergen, Norway, 1998-01-11, Tom Ivar Helbekkmo (tih@@Hamartun.Priv.NO).
@
