Thread: cidr
i didn't realize that anybody else was working on an IP address
data type or i'd've posted this six months ago when i first wrote
it. it lacks only the stuff needed to make it usable as a UNIQUE
KEY. it depends on BIND-8's libraries.
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.2).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1998-07-19 12:25 PDT by <vixie@bb.rc.vix.com>.
# Source directory was `/tmp_mnt/mb/mb0/user/vixie/src/postgres-cidrtype'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode name
# ------ ---------- ------------------------------------------
# 671 -r--r--r-- Makefile
# 4572 -r--r--r-- cidr.c
# 2877 -r--r--r-- cidr.source
# 3068 -r--r--r-- cidr.sql
#
save_IFS="${IFS}"
IFS="${IFS}:"
gettext_dir=FAILED
locale_dir=FAILED
first_param="$1"
for dir in $PATH
do
if test "$gettext_dir" = FAILED && test -f $dir/gettext \
&& ($dir/gettext --version >/dev/null 2>&1)
then
set `$dir/gettext --version 2>&1`
if test "$3" = GNU
then
gettext_dir=$dir
fi
fi
if test "$locale_dir" = FAILED && test -f $dir/shar \
&& ($dir/shar --print-text-domain-dir >/dev/null 2>&1)
then
locale_dir=`$dir/shar --print-text-domain-dir`
fi
done
IFS="$save_IFS"
if test "$locale_dir" = FAILED || test "$gettext_dir" = FAILED
then
echo=echo
else
TEXTDOMAINDIR=$locale_dir
export TEXTDOMAINDIR
TEXTDOMAIN=sharutils
export TEXTDOMAIN
echo="$gettext_dir/gettext -s"
fi
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
shar_touch=touch
else
shar_touch=:
echo
$echo 'WARNING: not restoring timestamps. Consider getting and'
$echo "installing GNU \`touch', distributed in GNU File Utilities..."
echo
fi
rm -f 1231235999 $$.touch
#
if mkdir _sh17086; then
$echo 'x -' 'creating lock directory'
else
$echo 'failed to create lock directory'
exit 1
fi
# ============= Makefile ==============
if test -f 'Makefile' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'Makefile' '(file already exists)'
else
$echo 'x -' extracting 'Makefile' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'Makefile' &&
ifndef PGDIR
PGDIR= /db0/local/postgresql-6.2
endif
X
SRCDIR= $(PGDIR)/src
X
include $(SRCDIR)/Makefile.global
X
CFLAGS+= -I$(PGDIR)/include -I$(PGDIR)/src/include -I$(LIBPQDIR)
CFLAGS+= -I/usr/local/bind/include
X
CLIBS+= -L/usr/local/bind/lib -lbind
X
TARGETS= cidr.sql cidr${DLSUFFIX}
X
DLSUFFIX=.so
X
all: $(TARGETS)
X
cidr${DLSUFFIX}: cidr.o
X shlicc2 -r -o cidr${DLSUFFIX} cidr.o -L/usr/local/bind/lib -lbind
X
install:
X $(MAKE) all
X cp -p cidr$(DLSUFFIX) $(LIBDIR)
X
%.sql: %.source
X rm -f $@; C=`pwd`; O=$$C; \
X if [ -d ${LIBDIR} ]; then O=${LIBDIR}; fi; \
X sed -e "s:_OBJWD_:$$O:g" \
X -e "s:_DLSUFFIX_:$(DLSUFFIX):g" \
X < $< > $@
X
clean:
X rm -f $(TARGETS) cidr.o
X
SHAR_EOF
$shar_touch -am 1108213897 'Makefile' &&
chmod 0444 'Makefile' ||
$echo 'restore of' 'Makefile' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'Makefile:' 'MD5 check failed'
ecb325bcab4a92f4fd5657cdc29a9f63 Makefile
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'Makefile'`"
test 671 -eq "$shar_count" ||
$echo 'Makefile:' 'original size' '671,' 'current size' "$shar_count!"
fi
fi
# ============= cidr.c ==============
if test -f 'cidr.c' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'cidr.c' '(file already exists)'
else
$echo 'x -' extracting 'cidr.c' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'cidr.c' &&
/*
X * cidr.c - Internal Classless InterDomain Routing entities for PostGreSQL
X *
X * Paul Vixie <paul@vix.com>, Internet Software Consortium, October 1997.
X *
X * $Id: cidr.c,v 1.4 1998/07/15 19:36:56 vixie Exp $
X */
X
/* Import. */
X
#include <sys/types.h>
#include <sys/socket.h>
X
#include <ctype.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
X
#include <netinet/in.h>
#include <arpa/inet.h>
#include <isc/misc.h>
X
#include "postgres.h"
#include "utils/palloc.h"
X
/* Define. */
X
#define cidr_min(a, b) (((a) < (b)) ? (a) : (b))
X
typedef struct {
X unsigned char family;
X unsigned char bits;
X unsigned char bytes[1]; /* This is really an open array. */
} cidr;
X
#define cidr_addrsize(fam) ((fam) == AF_INET ? 4 : -1)
#define cidr_size(addrsize) (sizeof(cidr) - sizeof(unsigned char) + addrsize)
X
/* Export. */
X
cidr * cidr_in(const char *);
char * cidr_out(const cidr *);
X
bool cidr_eq(const cidr *, const cidr *);
bool cidr_ne(const cidr *, const cidr *);
bool cidr_lt(const cidr *, const cidr *);
bool cidr_gt(const cidr *, const cidr *);
bool cidr_le(const cidr *, const cidr *);
bool cidr_ge(const cidr *, const cidr *);
bool cidr_sub(const cidr *, const cidr *);
bool cidr_subeq(const cidr *, const cidr *);
bool cidr_sup(const cidr *, const cidr *);
bool cidr_supeq(const cidr *, const cidr *);
int4 cidr_span(const cidr *, const cidr *);
int4 cidr_cmp(const cidr *, const cidr *);
X
/* Functions. */
X
cidr *
cidr_in(const char *src) {
X int bits, bytes;
X cidr *dst;
X
X bytes = cidr_addrsize(AF_INET);
X if (bytes == -1) {
X elog(WARN, "Programming error in cidr_in()");
X return (NULL);
X }
X dst = palloc(cidr_size(bytes));
X if (dst == NULL) {
X elog(WARN, "Unable to allocate memory in cidr_in()");
X return (NULL);
X }
X bits = inet_net_pton(AF_INET, src, &dst->bytes, bytes);
X if (bits < 0 || bits > 32) {
X elog(WARN, "Bad CIDR expression (%s)", src);
X pfree(dst);
X return (NULL);
X }
X dst->bits = (unsigned char)bits;
X return (dst);
}
X
char *
cidr_out(const cidr *src) {
X char *dst, tmp[sizeof "255.255.255.255/32"];
X
X if (inet_net_ntop(AF_INET, &src->bytes, src->bits,
X tmp, sizeof tmp) < 0) {
X elog(WARN, "Unable to format CIDR (%s)", strerror(errno));
X pfree(dst);
X return (NULL);
X }
X dst = palloc(strlen(tmp) + 1);
X if (dst == NULL) {
X elog(WARN, "Unable to allocate memory in cidr_out()");
X return (NULL);
X }
X strcpy(dst, tmp);
X return (dst);
}
X
/* Equality. */
X
bool
cidr_eq(const cidr *lhs, const cidr *rhs) {
X return (lhs->bits == rhs->bits &&
X bitncmp(lhs->bytes, rhs->bytes, lhs->bits) == 0);
}
X
bool
cidr_ne(const cidr *lhs, const cidr *rhs) {
X return (!cidr_eq(lhs, rhs));
}
X
/* Ordering. */
X
bool
cidr_lt(const cidr *lhs, const cidr *rhs) {
X int x = bitncmp(lhs->bytes, rhs->bytes,
X cidr_min(lhs->bits, rhs->bits));
X
X return (x < 0 || (x == 0 && lhs->bits < rhs->bits));
}
X
bool
cidr_le(const cidr *lhs, const cidr *rhs) {
X return (cidr_lt(lhs, rhs) || cidr_eq(lhs, rhs));
}
X
bool
cidr_gt(const cidr *lhs, const cidr *rhs) {
X int x = bitncmp(lhs->bytes, rhs->bytes,
X cidr_min(lhs->bits, rhs->bits));
X
X return (x > 0 || (x == 0 && lhs->bits > rhs->bits));
}
X
bool
cidr_ge(const cidr *lhs, const cidr *rhs) {
X return (cidr_gt(lhs, rhs) || cidr_eq(lhs, rhs));
}
X
/* Subnetting. */
X
bool
cidr_sub(const cidr *lhs, const cidr *rhs) {
X return (lhs->bits > rhs->bits &&
X bitncmp(lhs->bytes, rhs->bytes, rhs->bits) == 0);
}
X
bool
cidr_subeq(const cidr *lhs, const cidr *rhs) {
X return (lhs->bits >= rhs->bits &&
X bitncmp(lhs->bytes, rhs->bytes, rhs->bits) == 0);
}
X
/* Supernetting. */
X
bool
cidr_sup(const cidr *lhs, const cidr *rhs) {
X return (lhs->bits < rhs->bits &&
X bitncmp(lhs->bytes, rhs->bytes, lhs->bits) == 0);
}
X
bool
cidr_supeq(const cidr *lhs, const cidr *rhs) {
X return (lhs->bits <= rhs->bits &&
X bitncmp(lhs->bytes, rhs->bytes, lhs->bits) == 0);
}
X
int4
cidr_span(const cidr *lhs, const cidr *rhs) {
X const u_char *l = lhs->bytes, *r = rhs->bytes;
X int n = cidr_min(lhs->bits, rhs->bits);
X int b = n >> 3;
X int4 result = 0;
X u_int lb, rb;
X
X /* Find out how many full octets match. */
X while (b > 0 && *l == *r)
X b--, l++, r++, result += 8;
X /* Find out how many bits to check. */
X if (b == 0)
X b = n & 07;
X else
X b = 8;
X /* Find out how many bits match. */
X lb = *l, rb = *r;
X while (b > 0 && (lb & 0x80) == (rb & 0x80))
X b--, lb <<= 1, rb <<= 1, result++;
X return (result);
}
X
int4
cidr_cmp(const cidr *lhs, const cidr *rhs) {
X int x = bitncmp(lhs->bytes, rhs->bytes,
X cidr_min(lhs->bits, rhs->bits));
X
X if (x < 0)
X return (-1);
X if (x > 0)
X return (1);
X return (0);
}
SHAR_EOF
$shar_touch -am 0715123698 'cidr.c' &&
chmod 0444 'cidr.c' ||
$echo 'restore of' 'cidr.c' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'cidr.c:' 'MD5 check failed'
f8fd720dbffa7ab05d594c9953b75170 cidr.c
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'cidr.c'`"
test 4572 -eq "$shar_count" ||
$echo 'cidr.c:' 'original size' '4572,' 'current size' "$shar_count!"
fi
fi
# ============= cidr.source ==============
if test -f 'cidr.source' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'cidr.source' '(file already exists)'
else
$echo 'x -' extracting 'cidr.source' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'cidr.source' &&
---------------------------------------------------------------------------
--
-- cidr.sql-
-- This file defines operators Classless InterDomain Routing entities.
--
---------------------------------------------------------------------------
X
LOAD '_OBJWD_/cidr_DLSUFFIX_';
X
CREATE FUNCTION cidr_in(opaque)
X RETURNS cidr
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
CREATE FUNCTION cidr_out(opaque)
X RETURNS opaque
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
CREATE TYPE cidr (
X internallength = 6,
X input = cidr_in,
X output = cidr_out
);
X
CREATE FUNCTION cidr_cmp(cidr, cidr)
X RETURNS int4
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
-----------------------------
-- Create operators
-----------------------------
X
-- equality (=)
X
CREATE FUNCTION cidr_eq(cidr, cidr)
X RETURNS bool
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
CREATE OPERATOR = (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_eq,
X commutator = =
);
X
-- inequality (<>)
X
CREATE FUNCTION cidr_ne(cidr, cidr)
X RETURNS bool
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
CREATE OPERATOR <> (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_ne,
X commutator = <>
);
X
-- less (<, <=)
X
CREATE FUNCTION cidr_lt(cidr, cidr)
X RETURNS bool
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
CREATE OPERATOR < (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_lt
);
X
CREATE FUNCTION cidr_le(cidr, cidr)
X RETURNS bool
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
CREATE OPERATOR <= (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_le
);
X
-- greater (>, >=)
X
CREATE FUNCTION cidr_gt(cidr, cidr)
X RETURNS bool
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
CREATE OPERATOR > (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_gt
);
X
CREATE FUNCTION cidr_ge(cidr, cidr)
X RETURNS bool
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
CREATE OPERATOR >= (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_ge
);
X
-- subnet (<<, <<=)
X
CREATE FUNCTION cidr_sub(cidr, cidr)
X RETURNS bool
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
CREATE OPERATOR << (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_sub
);
X
CREATE FUNCTION cidr_subeq(cidr, cidr)
X RETURNS bool
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
CREATE OPERATOR <<= (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_subeq
);
X
-- supernet (>>, >>=)
X
CREATE FUNCTION cidr_sup(cidr, cidr)
X RETURNS bool
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
CREATE OPERATOR >> (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_sup
);
X
CREATE FUNCTION cidr_supeq(cidr, cidr)
X RETURNS bool
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
CREATE OPERATOR >>= (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_supeq
);
X
-- spanning (length of prefix match)
X
CREATE FUNCTION cidr_span(cidr, cidr)
X RETURNS int4
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
X
CREATE FUNCTION cidr_masklen(cidr)
X RETURNS int2
X AS '_OBJWD_/cidr_DLSUFFIX_'
X LANGUAGE 'c';
SHAR_EOF
$shar_touch -am 0719122498 'cidr.source' &&
chmod 0444 'cidr.source' ||
$echo 'restore of' 'cidr.source' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'cidr.source:' 'MD5 check failed'
dca27b8d433d030e5049bb04ad15df03 cidr.source
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'cidr.source'`"
test 2877 -eq "$shar_count" ||
$echo 'cidr.source:' 'original size' '2877,' 'current size' "$shar_count!"
fi
fi
# ============= cidr.sql ==============
if test -f 'cidr.sql' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'cidr.sql' '(file already exists)'
else
$echo 'x -' extracting 'cidr.sql' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'cidr.sql' &&
---------------------------------------------------------------------------
--
-- cidr.sql-
-- This file defines operators Classless InterDomain Routing entities.
--
---------------------------------------------------------------------------
X
LOAD '/var/home/vixie/postgres-cidrtype/cidr.so';
X
CREATE FUNCTION cidr_in(opaque)
X RETURNS cidr
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
X
CREATE FUNCTION cidr_out(opaque)
X RETURNS opaque
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
X
CREATE TYPE cidr (
X internallength = 5,
X input = cidr_in,
X output = cidr_out
);
X
CREATE FUNCTION cidr_cmp(cidr, cidr)
X RETURNS int4
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
X
-----------------------------
-- Create operators
-----------------------------
X
-- equality (=)
X
CREATE FUNCTION cidr_eq(cidr, cidr)
X RETURNS bool
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
X
CREATE OPERATOR = (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_eq,
X commutator = =
);
X
-- inequality (<>)
X
CREATE FUNCTION cidr_ne(cidr, cidr)
X RETURNS bool
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
X
CREATE OPERATOR <> (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_ne,
X commutator = <>
);
X
-- less (<, <=)
X
CREATE FUNCTION cidr_lt(cidr, cidr)
X RETURNS bool
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
X
CREATE OPERATOR < (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_lt
);
X
CREATE FUNCTION cidr_le(cidr, cidr)
X RETURNS bool
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
X
CREATE OPERATOR <= (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_le
);
X
-- greater (>, >=)
X
CREATE FUNCTION cidr_gt(cidr, cidr)
X RETURNS bool
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
X
CREATE OPERATOR > (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_gt
);
X
CREATE FUNCTION cidr_ge(cidr, cidr)
X RETURNS bool
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
X
CREATE OPERATOR >= (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_ge
);
X
-- subnet (<<, <<=)
X
CREATE FUNCTION cidr_sub(cidr, cidr)
X RETURNS bool
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
X
CREATE OPERATOR << (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_sub
);
X
CREATE FUNCTION cidr_subeq(cidr, cidr)
X RETURNS bool
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
X
CREATE OPERATOR <<= (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_subeq
);
X
-- supernet (>>, >>=)
X
CREATE FUNCTION cidr_sup(cidr, cidr)
X RETURNS bool
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
X
CREATE OPERATOR >> (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_sup
);
X
CREATE FUNCTION cidr_supeq(cidr, cidr)
X RETURNS bool
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
X
CREATE OPERATOR >>= (
X leftarg = cidr,
X rightarg = cidr,
X procedure = cidr_supeq
);
X
-- spanning (length of prefix match)
X
CREATE FUNCTION cidr_span(cidr, cidr)
X RETURNS int4
X AS '/var/home/vixie/postgres-cidrtype/cidr.so'
X LANGUAGE 'c';
SHAR_EOF
$shar_touch -am 1201183797 'cidr.sql' &&
chmod 0444 'cidr.sql' ||
$echo 'restore of' 'cidr.sql' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'cidr.sql:' 'MD5 check failed'
097a4f0f2b5915fc5478976233c714f3 cidr.sql
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'cidr.sql'`"
test 3068 -eq "$shar_count" ||
$echo 'cidr.sql:' 'original size' '3068,' 'current size' "$shar_count!"
fi
fi
rm -fr _sh17086
exit 0
Paul A Vixie <vixie@vix.com> writes: > i didn't realize that anybody else was working on an IP address > data type or i'd've posted this six months ago when i first wrote > it. it lacks only the stuff needed to make it usable as a UNIQUE > KEY. it depends on BIND-8's libraries. Interesting -- looks nice at first glance, and does some things that neither Aleksei nor I had thought of. I guess a merge of the three variations is in order. At least I'll be doing that locally, and will make the result available. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
> Paul A Vixie <vixie@vix.com> writes: > > > i didn't realize that anybody else was working on an IP address > > data type or i'd've posted this six months ago when i first wrote > > it. it lacks only the stuff needed to make it usable as a UNIQUE > > KEY. it depends on BIND-8's libraries. > > Interesting -- looks nice at first glance, and does some things that > neither Aleksei nor I had thought of. I guess a merge of the three > variations is in order. At least I'll be doing that locally, and will > make the result available. OK, perhaps I will not apply the patch, and wait for a merged version. Comments? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> > i didn't realize that anybody else was working on an IP address > > data type or i'd've posted this six months ago when i first wrote > > it. it lacks only the stuff needed to make it usable as a UNIQUE > > KEY. it depends on BIND-8's libraries. > > Interesting -- looks nice at first glance, and does some things that > neither Aleksei nor I had thought of. I guess a merge of the three > variations is in order. At least I'll be doing that locally, and will > make the result available. i would be happy if given a chance to consult with whomever wants to do the work of merging the various ipaddr proposals, and would even do some work if appropriate. i would like an indexable "cidr" data type (you ought not call it an ipaddr, it can be either a net or a host, and the net is variable sized, so it really is a "cidr") to become part of the standard postgres system. but i mostly want to use it in apps, and i mostly wanted to learn how to extend postgres -- i have no undying love for the implementation i posted here, nor do i know the process for making this a standard data type. so, i will help if someone else is driving.
> > > i didn't realize that anybody else was working on an IP address > > > data type or i'd've posted this six months ago when i first wrote > > > it. it lacks only the stuff needed to make it usable as a UNIQUE > > > KEY. it depends on BIND-8's libraries. > > > > Interesting -- looks nice at first glance, and does some things that > > neither Aleksei nor I had thought of. I guess a merge of the three > > variations is in order. At least I'll be doing that locally, and will > > make the result available. > > i would be happy if given a chance to consult with whomever wants to do > the work of merging the various ipaddr proposals, and would even do some > work if appropriate. i would like an indexable "cidr" data type (you > ought not call it an ipaddr, it can be either a net or a host, and the > net is variable sized, so it really is a "cidr") to become part of the > standard postgres system. but i mostly want to use it in apps, and i > mostly wanted to learn how to extend postgres -- i have no undying love > for the implementation i posted here, nor do i know the process for making > this a standard data type. so, i will help if someone else is driving. Sounds like a plan. Paul is a DNS expert, and we have people involved who know PostgreSQL well. As far as the name, we just want a name that makes it clear to novices what the module does. ip_and_mac is pretty clear. I have no idea what a cidr is. If you can think of a more descriptive name, let's go for it. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> As far as the name, we just want a name that makes it clear to novices what > the module does. ip_and_mac is pretty clear. I have no idea what a cidr > is. If you can think of a more descriptive name, let's go for it. cidr = classless internet domain routing. it's the "204.152.184/21" notation. i'm not sure we need a type name that makes sense to novices. what we need is an example in the "type range" column. if we can say that int2's allowed ranges are 0 to 65535 and have folks get what we mean without further intro, then we can teach novices about cidr by saying that allowable ranges are 0/0 through 255.255.255.255/32.
On Mon, 20 Jul 1998, Paul A Vixie wrote:
> > As far as the name, we just want a name that makes it clear to novices what
> > the module does. ip_and_mac is pretty clear. I have no idea what a cidr
> > is. If you can think of a more descriptive name, let's go for it.
>
> cidr = classless internet domain routing. it's the "204.152.184/21" notation.
>
> i'm not sure we need a type name that makes sense to novices. what we need
> is an example in the "type range" column. if we can say that int2's allowed
> ranges are 0 to 65535 and have folks get what we mean without further intro,
> then we can teach novices about cidr by saying that allowable ranges are 0/0
> through 255.255.255.255/32.
I have to agree with Paul here...its like mis-representing tuples
as rows and fields as columns. It means the same, but it *isn't* the
proper terminology. By using 'ip_and_mac' where it should be 'cidr', we
are just propogating incorrect terminology...
With that in mind, can we work at having a 'cidr' type as part of
the overall system, vs contrib? I know that *I* would use it alot more if
I didn't have to think of loading it seperately...and I can think of at
least two of my projects that I'd use it in...
Considering that we are now up to three ppl out there that are
willing to work on this, I think we should be able to come up with a
'consensus' as to what we are going to be considering "the standard" for
the base implementation?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> On Mon, 20 Jul 1998, Paul A Vixie wrote: > > > > As far as the name, we just want a name that makes it clear to novices what > > > the module does. ip_and_mac is pretty clear. I have no idea what a cidr > > > is. If you can think of a more descriptive name, let's go for it. > > > > cidr = classless internet domain routing. it's the "204.152.184/21" notation. > > > > i'm not sure we need a type name that makes sense to novices. what we need > > is an example in the "type range" column. if we can say that int2's allowed > > ranges are 0 to 65535 and have folks get what we mean without further intro, > > then we can teach novices about cidr by saying that allowable ranges are 0/0 > > through 255.255.255.255/32. Paul, yes, I have seen this address style on several machines, and I understand it supersede the class A,B,C addresses by allowing arbitrary netmasks. We can call it cidr. That is fine. I was just concerned that if we put it in contrib, that people who have never heard of cidr, like me, can recognize the usefulness of the type for their applications. Also, I would assume we can handle old-style non-cidr address just as cleanly, so both cidr and non-cidr can use the same type and functions. > I have to agree with Paul here...its like mis-representing tuples > as rows and fields as columns. It means the same, but it *isn't* the > proper terminology. By using 'ip_and_mac' where it should be 'cidr', we > are just propagating incorrect terminology... > > With that in mind, can we work at having a 'cidr' type as part of > the overall system, vs contrib? I know that *I* would use it alot more if > I didn't have to think of loading it separately...and I can think of at > least two of my projects that I'd use it in... > > Considering that we are now up to three ppl out there that are > willing to work on this, I think we should be able to come up with a > 'consensus' as to what we are going to be considering "the standard" for > the base implementation? Yes, I agree, this is a HOT type, and should be installed in the default system. Contrib is for testing/narrow audience, and this type certainly should be mainstream. This is the third generation of the type, with a wide audience. int8 is also coming into the main tree via Thomas. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> > As far as the name, we just want a name that makes it clear to novices what > > the module does. ip_and_mac is pretty clear. I have no idea what a cidr > > is. If you can think of a more descriptive name, let's go for it. > > cidr = classless internet domain routing. it's the "204.152.184/21" notation. > > i'm not sure we need a type name that makes sense to novices. what we need > is an example in the "type range" column. if we can say that int2's allowed > ranges are 0 to 65535 and have folks get what we mean without further intro, > then we can teach novices about cidr by saying that allowable ranges are 0/0 > through 255.255.255.255/32. If we make it a standard type, not contrib, we can add a pg_description entry for it so \dT shows the valid range of values. Functions/operators also get descriptions for \do and \df. Should be easy. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
On Mon, 20 Jul 1998, Bruce Momjian wrote:
> We can call it cidr. That is fine. I was just concerned that if we put
> it in contrib, that people who have never heard of cidr, like me, can
> recognize the usefulness of the type for their applications.
IMHO, those that will use it, will know what it is...AFAIK, CIDR
is a pretty generic/standard term, one that I've known for at least 6
years now, so it isn't really "new-style".
> Yes, I agree, this is a HOT type, and should be installed in the default
> system. Contrib is for testing/narrow audience, and this type certainly
> should be mainstream. This is the third generation of the type, with a
> wide audience. int8 is also coming into the main tree via Thomas.
Contrib for v6.4, mainstream by v6.5?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> On Mon, 20 Jul 1998, Bruce Momjian wrote: > > > We can call it cidr. That is fine. I was just concerned that if we put > > it in contrib, that people who have never heard of cidr, like me, can > > recognize the usefulness of the type for their applications. > > IMHO, those that will use it, will know what it is...AFAIK, CIDR > is a pretty generic/standard term, one that I've known for at least 6 > years now, so it isn't really "new-style". > > > Yes, I agree, this is a HOT type, and should be installed in the default > > system. Contrib is for testing/narrow audience, and this type certainly > > should be mainstream. This is the third generation of the type, with a > > wide audience. int8 is also coming into the main tree via Thomas. > > Contrib for v6.4, mainstream by v6.5? ip_and_mac was contrib for 6.3. Why not mainstream for 6.4? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
On Mon, 20 Jul 1998, Bruce Momjian wrote: > As far as the name, we just want a name that makes it clear to novices > what the module does. ip_and_mac is pretty clear. I have no idea what > a cidr is. If you can think of a more descriptive name, let's go for > it. I think most people who would use the IP related types do know what a CIDR is. An IP address should be just that, a discrete IP, no netmask, nothing. A CIDR is a type able to represent a range of IP addresses (what one of the previous patches did by storing an address and a netmask.) MAC addresses speak for themselves. I'll let others describe all the nifty functions that the first two types will/can have (IP - IP, IP - CIDR, CIDR - CIDR). /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */
On Mon, 20 Jul 1998, Bruce Momjian wrote:
> > On Mon, 20 Jul 1998, Bruce Momjian wrote:
> >
> > > We can call it cidr. That is fine. I was just concerned that if we put
> > > it in contrib, that people who have never heard of cidr, like me, can
> > > recognize the usefulness of the type for their applications.
> >
> > IMHO, those that will use it, will know what it is...AFAIK, CIDR
> > is a pretty generic/standard term, one that I've known for at least 6
> > years now, so it isn't really "new-style".
> >
> > > Yes, I agree, this is a HOT type, and should be installed in the default
> > > system. Contrib is for testing/narrow audience, and this type certainly
> > > should be mainstream. This is the third generation of the type, with a
> > > wide audience. int8 is also coming into the main tree via Thomas.
> >
> > Contrib for v6.4, mainstream by v6.5?
>
> ip_and_mac was contrib for 6.3. Why not mainstream for 6.4?
That works even better...:)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Thus spake Bruce Momjian
> Paul, yes, I have seen this address style on several machines, and I
> understand it supersede the class A,B,C addresses by allowing arbitrary
> netmasks.
Exactly.
> We can call it cidr. That is fine. I was just concerned that if we put
> it in contrib, that people who have never heard of cidr, like me, can
> recognize the usefulness of the type for their applications.
CIDR is getting to be pretty well known. Most people who need the type
should understand it.
> Also, I would assume we can handle old-style non-cidr address just as
> cleanly, so both cidr and non-cidr can use the same type and functions.
Yes. The old class system is just 3 special cases (Well, 4 really) of
CIDR.
> Yes, I agree, this is a HOT type, and should be installed in the default
> system. Contrib is for testing/narrow audience, and this type certainly
> should be mainstream. This is the third generation of the type, with a
> wide audience. int8 is also coming into the main tree via Thomas.
I missed some of the earlier discussion. Is there going to be a separate
IP type or is that just x.x.x.x/32? I like the idea of a host type as
well. I would love to sort my IPs and have 198.96.119.99 precede
198.96.119.100.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
> With that in mind, can we work at having a 'cidr' type as part of > the overall system, vs contrib? I know that *I* would use it alot more if > I didn't have to think of loading it seperately...and I can think of at > least two of my projects that I'd use it in... me too. i'm already using it in fact. i just don't know how to make it indexable. having it be a standard type, with someone who knows postgres making it indexable, would be really great for the MAPS project and for some WHOIS/LDAP stuff we're doing here. > Considering that we are now up to three ppl out there that are > willing to work on this, I think we should be able to come up with a > 'consensus' as to what we are going to be considering "the standard" for > the base implementation? i remain ready to help anyone who promises to drive this thing. and while i feel that "cidr" is the right name, i don't feel it strongly enough to refuse to help unless that name is chosen. i need the functionality, and if it appears under some other name i will use it under that name.
> Also, I would assume we can handle old-style non-cidr address just as > cleanly, so both cidr and non-cidr can use the same type and functions. the implementation i sent around yesterday does this just fine. or rather it makes useful assumptions if no "/" is given, and it always prints the "/".
> > Yes, I agree, this is a HOT type, and should be installed in the default > > system. Contrib is for testing/narrow audience, and this type certainly > > should be mainstream. This is the third generation of the type, with a > > wide audience. int8 is also coming into the main tree via Thomas. > > I missed some of the earlier discussion. Is there going to be a separate > IP type or is that just x.x.x.x/32? I like the idea of a host type as > well. I would love to sort my IPs and have 198.96.119.99 precede > 198.96.119.100. My guess is that it is going to output x.x.x.x/32, but we should supply a function so they can get just the IP or the mask from the type. That way, people who don't want the cidr format can pull out the part they want. If they don't specify a netmask when they load the value, perhaps we use the standard class A,B,C netmasks. How you specify a HOST address using the non-cidr format, I really don't know. I am sure the experts will hash it out before 6.4 beta on September 1. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> I missed some of the earlier discussion. Is there going to be a separate > IP type or is that just x.x.x.x/32? I like the idea of a host type as > well. I would love to sort my IPs and have 198.96.119.99 precede > 198.96.119.100. the ordering functions given in the implementation i posted here yesterday do that, and they also show 192.5.5/24 as being "before" 192.5.5.0/32, which is important for those of us who import routing tables into database tables. i don't see a need for a separate type for /32's; if someone enters just the dotted quad (198.96.119.100 for example) the "/32" will be assumed. i'd be willing to see the "/32" stripped off in the output function since it's a bit redundant -- i didn't do that but it's out of habit rather than strong belief. if folks really can't get behind "CIDR" then may i suggest "INET"? it's not a "NET" or an "IPADDR" or "INADDR" or "INNET" or "HOST". it is capable of representing either a network or a host, classlessly. that makes it a CIDR to those in the routing or registry business. and before someone asks: no, it is not IPv4-specific. my implementation encodes the address family and is capable of supporting IPv6 if the "internallength" wants to be 13 or if someone knows how to make it variable-length.
> > With that in mind, can we work at having a 'cidr' type as part of > > the overall system, vs contrib? I know that *I* would use it alot more if > > I didn't have to think of loading it seperately...and I can think of at > > least two of my projects that I'd use it in... > > me too. i'm already using it in fact. i just don't know how to make it > indexable. having it be a standard type, with someone who knows postgres > making it indexable, would be really great for the MAPS project and for > some WHOIS/LDAP stuff we're doing here. > > > Considering that we are now up to three ppl out there that are > > willing to work on this, I think we should be able to come up with a > > 'consensus' as to what we are going to be considering "the standard" for > > the base implementation? > > i remain ready to help anyone who promises to drive this thing. and while > i feel that "cidr" is the right name, i don't feel it strongly enough to > refuse to help unless that name is chosen. i need the functionality, and > if it appears under some other name i will use it under that name. We will keep the 'cidr' name, as far as I am concerned. People seem to know what it means, and we will mention it is for IP network/host addresses. In fact, if it is installed in the system, it will be hard for anyone looking for an IP type to miss. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> > With that in mind, can we work at having a 'cidr' type as part of > > the overall system, vs contrib? I know that *I* would use it alot more if > > I didn't have to think of loading it seperately...and I can think of at > > least two of my projects that I'd use it in... > > me too. i'm already using it in fact. i just don't know how to make it > indexable. having it be a standard type, with someone who knows postgres > making it indexable, would be really great for the MAPS project and for > some WHOIS/LDAP stuff we're doing here. > > > Considering that we are now up to three ppl out there that are > > willing to work on this, I think we should be able to come up with a > > 'consensus' as to what we are going to be considering "the standard" for > > the base implementation? > > i remain ready to help anyone who promises to drive this thing. and while > i feel that "cidr" is the right name, i don't feel it strongly enough to > refuse to help unless that name is chosen. i need the functionality, and > if it appears under some other name i will use it under that name. This could clearly be a KILLER APP/TYPE for us. This is a pretty sophisticated use of our type system. Indexing should present no problems. We supply the comparison routines and plug them in, and the optimizer automatically uses the indexes. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> My guess is that it is going to output x.x.x.x/32, but we should supply
> a function so they can get just the IP or the mask from the type. That
> way, people who don't want the cidr format can pull out the part they
> want.
this i don't understand. why would you want only one part of it? if you
want to do address arithmetic then you need specific OR and AND and NOT
functions -- like making a broadcast address if all you know is your address
and netmask. but why would you want to know the mantissa without the scale?
> If they don't specify a netmask when they load the value, perhaps we use
> the standard class A,B,C netmasks. How you specify a HOST address using
> the non-cidr format, I really don't know. I am sure the experts will
> hash it out before 6.4 beta on September 1.
classful assumptions are out of fashion, outdated, and dangerous. consider:
"16" -> "16/8" -> "16.0.0.0/8"
"128" -> "128/16" -> "128.0.0.0/16"
"192" -> "192/24" -> "192.0.0.0/24"
not very helpful. the implementation of "cidr" that i posted here yesterday
uses the BIND-8 functions for representational conversion. those functions
assume that a text representation with no "/" given has as many bits as the
number of octets they fully cover:
"16" -> "16/8"
"128" -> "128/8"
"192" -> "192/8"
"127.1" -> "127.1/16"
this is how a Cisco router would interpret such routes if "ip classless" is
enabled and static routes were being entered. "ip classless" is a prereq-
uisite for running OSPF, RIPv2, or BGP4. in other words it's pervasive.
BIND follows RFC 1884 in this regard, and deviates significantly from both
classful assumptions and the old BSD standard, which would treat "127.1" as
"127.0.0.1". this burned on some old /etc/rc files but it was the right
thing to do and now that the world has gotten over the scars, let's not run
backwards.
the IETF's CIDR project was long running, painful, and successful.
> This could clearly be a KILLER APP/TYPE for us. This is a pretty > sophisticated use of our type system. Indexing should present no > problems. We supply the comparison routines and plug them in, and the > optimizer automatically uses the indexes. i'd like that to be true. but the section of the manual which describes this isn't as clear as the examples (the COMPLEX type in particular) in the contrib/ directory at the time i started the work. figuring out what OID my comparison operators happened to get and plugging these values into a PG_OPERATOR insert was just more than i could figure out how to automate. other than the OID thing i really love the postgres type system, btw, and i can't see why anybody would ever use MySQL (or Oracle) unless it has the same feature.
> > I missed some of the earlier discussion. Is there going to be a separate > > IP type or is that just x.x.x.x/32? I like the idea of a host type as > > well. I would love to sort my IPs and have 198.96.119.99 precede > > 198.96.119.100. > > the ordering functions given in the implementation i posted here yesterday > do that, and they also show 192.5.5/24 as being "before" 192.5.5.0/32, which > is important for those of us who import routing tables into database tables. > > i don't see a need for a separate type for /32's; if someone enters just the > dotted quad (198.96.119.100 for example) the "/32" will be assumed. i'd be > willing to see the "/32" stripped off in the output function since it's a bit > redundant -- i didn't do that but it's out of habit rather than strong belief. The only problem is that if we assume /32, how do we auto-netmask class A/B/C addresses? I guess we don't. If they want a netmask, they are going to have to specify it in cidr format. I will be honest. I always found the network/host IP address distinction to be very unclearly outlined in old/non-cidr address displays, and this causes major confusion for me when trying to figure out how things are configured. > if folks really can't get behind "CIDR" then may i suggest "INET"? it's not > a "NET" or an "IPADDR" or "INADDR" or "INNET" or "HOST". it is capable of > representing either a network or a host, classlessly. that makes it a CIDR > to those in the routing or registry business. and before someone asks: no, > it is not IPv4-specific. my implementation encodes the address family and > is capable of supporting IPv6 if the "internallength" wants to be 13 or if > someone knows how to make it variable-length. I like INET too. It is up to you. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> > My guess is that it is going to output x.x.x.x/32, but we should supply
> > a function so they can get just the IP or the mask from the type. That
> > way, people who don't want the cidr format can pull out the part they
> > want.
>
> this i don't understand. why would you want only one part of it? if you
> want to do address arithmetic then you need specific OR and AND and NOT
> functions -- like making a broadcast address if all you know is your address
> and netmask. but why would you want to know the mantissa without the scale?
I guess I thought someone might want to have ipaddr() and netmask()
functions so they can do:
x = 192.7.34.21/24
ipaddr(x) -> 192.7.34.21
netmask(x) -> 255.255.255.0
x = 192.7.0.0/16
ipaddr(x) -> 192.7.0.0
netmask(x) -> 255.255.0.0
These function are defined on the cidr type, and can be called if
someone wants the old output format.
>
> > If they don't specify a netmask when they load the value, perhaps we use
> > the standard class A,B,C netmasks. How you specify a HOST address using
> > the non-cidr format, I really don't know. I am sure the experts will
> > hash it out before 6.4 beta on September 1.
>
> classful assumptions are out of fashion, outdated, and dangerous. consider:
>
> "16" -> "16/8" -> "16.0.0.0/8"
> "128" -> "128/16" -> "128.0.0.0/16"
> "192" -> "192/24" -> "192.0.0.0/24"
>
> not very helpful. the implementation of "cidr" that i posted here yesterday
> uses the BIND-8 functions for representational conversion. those functions
> assume that a text representation with no "/" given has as many bits as the
> number of octets they fully cover:
>
> "16" -> "16/8"
> "128" -> "128/8"
> "192" -> "192/8"
> "127.1" -> "127.1/16"
>
> this is how a Cisco router would interpret such routes if "ip classless" is
> enabled and static routes were being entered. "ip classless" is a prereq-
> uisite for running OSPF, RIPv2, or BGP4. in other words it's pervasive.
>
> BIND follows RFC 1884 in this regard, and deviates significantly from both
> classful assumptions and the old BSD standard, which would treat "127.1" as
> "127.0.0.1". this burned on some old /etc/rc files but it was the right
> thing to do and now that the world has gotten over the scars, let's not run
> backwards.
>
> the IETF's CIDR project was long running, painful, and successful.
Yes, the 127.1 ambiguity was very strange. netstat -rn is very hard to
understand using the old format.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
> > This could clearly be a KILLER APP/TYPE for us. This is a pretty > > sophisticated use of our type system. Indexing should present no > > problems. We supply the comparison routines and plug them in, and the > > optimizer automatically uses the indexes. > > i'd like that to be true. but the section of the manual which describes > this isn't as clear as the examples (the COMPLEX type in particular) in > the contrib/ directory at the time i started the work. figuring out what > OID my comparison operators happened to get and plugging these values into > a PG_OPERATOR insert was just more than i could figure out how to automate. Doing complex stuff like indexing with contrib stuff is tricky, and one reason we want to move stuff out of there as it becomes popular. It is just too hard for someone not experienced with the code to implement. Add to this the fact that the oid at the time of contrib installation will change every time you install it, so it is even harder/impossible to automate. > > other than the OID thing i really love the postgres type system, btw, and i > can't see why anybody would ever use MySQL (or Oracle) unless it has the > same feature. Yep. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
Replies to three messages here. > From: Bruce Momjian <maillist@candle.pha.pa.us> > Date: Tue, 21 Jul 1998 01:13:34 -0400 (EDT) > > The only problem is that if we assume /32, how do we auto-netmask class > A/B/C addresses? I guess we don't. If they want a netmask, they are > going to have to specify it in cidr format. Right. But read on -- what you're calling a netmask is really a prefix length, and I think there's some confusion as to what it is. > I will be honest. I always found the network/host IP address > distinction to be very unclearly outlined in old/non-cidr address > displays, and this causes major confusion for me when trying to figure > out how things are configured. Me too. > I like INET too. It is up to you. How do folks feel about polymorphism between IPv4 and IPv6? Should we (a) make it work (either by making internal_length=10 or going variable length) or (b) just make this thing IPv4 only and take care of IPv6 separately/later? I've started to wonder if we ought to call the type INET and limit it to V4. (In the C socket bindings, IPv6 addresses are in_addr6 / sockaddr_in6, and the address family is AF_INET6 -- I don't know whether to plan on reflecting this in the postgres types, i.e., use a separate one for IPv6, or not.) > From: Bruce Momjian <maillist@candle.pha.pa.us> > Date: Tue, 21 Jul 1998 01:30:05 -0400 (EDT) > > > ... but why would you want to know the mantissa without the scale? > > I guess I thought someone might want to have ipaddr() and netmask() > functions so they can do: > > x = 192.7.34.21/24 > ipaddr(x) -> 192.7.34.21 > netmask(x) -> 255.255.255.0 This is the downreference from above. It does not work that way. /24 is not a shorthand for specifying a netmask -- in CIDR, it's a "prefix length". That means "192.7.34.21/24" is either (a) a syntax error or (b) equivilent to "192.7.34/24". Btw, it appears from my research that the BIND functions *do* impute a "class" if (a) no "/width" is specified and (b) the classful interpretation would be longer than the classless interpretation. No big deal but it qualifies something I said earlier so I thought I'd mention it. > x = 192.7.0.0/16 > ipaddr(x) -> 192.7.0.0 > netmask(x) -> 255.255.0.0 > > These function are defined on the cidr type, and can be called if > someone wants the old output format. Can we wait and see if someone misses / asks for these before we make them? > ..., the 127.1 ambiguity was very strange. netstat -rn is very hard to > understand using the old format. I was amazed at the number of people who had hardwired "127.1" though :-(. > From: Bruce Momjian <maillist@candle.pha.pa.us> > Date: Tue, 21 Jul 1998 01:33:41 -0400 (EDT) > > Doing complex stuff like indexing with contrib stuff is tricky, and one > reason we want to move stuff out of there as it becomes popular. It is > just too hard for someone not experienced with the code to implement. > Add to this the fact that the oid at the time of contrib installation > will change every time you install it, so it is even harder/impossible > to automate. Perhaps we ought to make new type insertion easier since it's so cool?
On Mon, 20 Jul 1998, Paul A Vixie wrote:
> > Also, I would assume we can handle old-style non-cidr address just as
> > cleanly, so both cidr and non-cidr can use the same type and functions.
>
> the implementation i sent around yesterday does this just fine. or rather
> it makes useful assumptions if no "/" is given, and it always prints the "/".
Does anyone have any objections to using Paul's implementation as
"the base implementation", to be inserted into the main stream code now,
and built up from there?
Assuming no objections, Paul...can you get your implementation
merged into the 'main stream code' vs 'contrib' and submit an appropriate
patch for it? The sooner we get it into the main stream, the sooner more
ppl are playing with it, testing it, and suggesting/submitting changes to
it...
And the type is to be a 'CIDR', which is the appropriate
terminology for what it is...those that need it, will know what it is
*shrug*
On Tue, 21 Jul 1998, Bruce Momjian wrote:
> > if folks really can't get behind "CIDR" then may i suggest "INET"? it's not
> > a "NET" or an "IPADDR" or "INADDR" or "INNET" or "HOST". it is capable of
> > representing either a network or a host, classlessly. that makes it a CIDR
> > to those in the routing or registry business. and before someone asks: no,
> > it is not IPv4-specific. my implementation encodes the address family and
> > is capable of supporting IPv6 if the "internallength" wants to be 13 or if
> > someone knows how to make it variable-length.
>
> I like INET too. It is up to you
I'm sticking to this one like glue...the proper terminology is a
CIDR...using anything else would be tailoring to "those that don't want to
know better", which I believe is the business Micro$loth is in, no?
If you don't know what a CIDR is, you probably shouldn't be using
it and should get out of networking...
On Mon, 20 Jul 1998, Paul A Vixie wrote:
> > I like INET too. It is up to you.
>
> How do folks feel about polymorphism between IPv4 and IPv6? Should we (a)
> make it work (either by making internal_length=10 or going variable length)
> or (b) just make this thing IPv4 only and take care of IPv6 separately/later?
Not sure about b, but doesn't FreeBSD (at least) already support
IPv6? If so, I imagine that Linux does too? How much "later" are we
talking about here?
I'm sorry, but the IPv4 vs IPv6 issue hasnt' been something I've
followed much, so don't know the differences...:(
On Mon, 20 Jul 1998, Paul A Vixie wrote: > i don't see a need for a separate type for /32's; if someone enters just the > dotted quad (198.96.119.100 for example) the "/32" will be assumed. i'd be > willing to see the "/32" stripped off in the output function since it's a bit > redundant -- i didn't do that but it's out of habit rather than strong belief. I don't see a problem with having a separate type for /32's. It doesn't hurt anything, and it takes up less room that a CIDR. When you've got several million records this becomes an issue. (Not from a perspective of space, but more data requires more time to muck through during queries.) Plus, it would enable me to use my existing data without reloading. (ignoring the fact that 6.4 will probably require this.) /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */
Paul A Vixie wrote: > > I like INET too. It is up to you. > > How do folks feel about polymorphism between IPv4 and IPv6? Should we (a) > make it work (either by making internal_length=10 or going variable length) > or (b) just make this thing IPv4 only and take care of IPv6 separately/later? Making it IPv4 only just means we'll have to do it again later, and having IPv6 functionality now would be good for those of us who are currently working with IPv6 networks... Nick Bastin Systems Administrator RBb Systems
> > I like INET too. It is up to you. > > How do folks feel about polymorphism between IPv4 and IPv6? Should we (a) > make it work (either by making internal_length=10 or going variable length) > or (b) just make this thing IPv4 only and take care of IPv6 separately/later? I say stick with IPv4 at this point. We can always change it in future upgrades. dump/reload will handle any changes in the internal format. > > I've started to wonder if we ought to call the type INET and limit it to V4. > (In the C socket bindings, IPv6 addresses are in_addr6 / sockaddr_in6, and > the address family is AF_INET6 -- I don't know whether to plan on reflecting > this in the postgres types, i.e., use a separate one for IPv6, or not.) We can call it INET now, and change it to INET4/INET6 if we decide we want separate types for the two address types. > > > From: Bruce Momjian <maillist@candle.pha.pa.us> > > Date: Tue, 21 Jul 1998 01:30:05 -0400 (EDT) > > > > > ... but why would you want to know the mantissa without the scale? > > > > I guess I thought someone might want to have ipaddr() and netmask() > > functions so they can do: > > > > x = 192.7.34.21/24 > > ipaddr(x) -> 192.7.34.21 > > netmask(x) -> 255.255.255.0 > > This is the downreference from above. It does not work that way. /24 is > not a shorthand for specifying a netmask -- in CIDR, it's a "prefix length". > That means "192.7.34.21/24" is either (a) a syntax error or (b) equivilent > to "192.7.34/24". How do we store the netmask? Is that a separate field? > > Btw, it appears from my research that the BIND functions *do* impute a "class" > if (a) no "/width" is specified and (b) the classful interpretation would be > longer than the classless interpretation. No big deal but it qualifies > something I said earlier so I thought I'd mention it. > > > x = 192.7.0.0/16 > > ipaddr(x) -> 192.7.0.0 > > netmask(x) -> 255.255.0.0 > > > > These function are defined on the cidr type, and can be called if > > someone wants the old output format. > > Can we wait and see if someone misses / asks for these before we make them? Suppose I want to retrieve only 'host' addresses. How do we do that? > > Doing complex stuff like indexing with contrib stuff is tricky, and one > > reason we want to move stuff out of there as it becomes popular. It is > > just too hard for someone not experienced with the code to implement. > > Add to this the fact that the oid at the time of contrib installation > > will change every time you install it, so it is even harder/impossible > > to automate. > > Perhaps we ought to make new type insertion easier since it's so cool? Yep, it is cool. When the code is installed as a standard part of the backend, you have more facilities to install types. There are examples of many other types in the include/catalog/*.h files, so you just pick one and duplicate the proper partsTrying to do that with an SQL statement is really messy, particularly because the standard types DON'T use SQL to install themselves. You also must specify unique OIDs for these new entries. Also, the terminology is not something that many people are familiar with, so a lot of it is having the user understand what they need to do. The manuals do a pretty good job. If you have any specific ideas, or things that got you confused that we should clearify, please let us know. Fortunately, there are only a few types in the /contrib area, and as you have learned. As people find the types useful, we want to move them into the main source. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> On Mon, 20 Jul 1998, Paul A Vixie wrote: > > > > Also, I would assume we can handle old-style non-cidr address just as > > > cleanly, so both cidr and non-cidr can use the same type and functions. > > > > the implementation i sent around yesterday does this just fine. or rather > > it makes useful assumptions if no "/" is given, and it always prints the "/". > > Does anyone have any objections to using Paul's implementation as > "the base implementation", to be inserted into the main stream code now, > and built up from there? It is already being worked on by one of the ip_and_mac developers. He is merging the types. We need him to work on it because he understands PostgreSQL better. > > Assuming no objections, Paul...can you get your implementation > merged into the 'main stream code' vs 'contrib' and submit an appropriate > patch for it? The sooner we get it into the main stream, the sooner more > ppl are playing with it, testing it, and suggesting/submitting changes to > it... Again, it is being worked on. I don't think Paul wants to get into installing in into the main tree. It is quite a job. We may need to increase the max system oid to get us more available oids. > And the type is to be a 'CIDR', which is the appropriate > terminology for what it is...those that need it, will know what it is > *shrug* I use IP addresses and didn't know. I am also hoping we can allow storage of old and cidr types in the same type, at least superficially. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
"Matthew N. Dodd" <winter@jurai.net> writes:
> Plus, it would enable me to use my existing data without reloading.
> (ignoring the fact that 6.4 will probably require this.)
6.4 definitely will require a database reload, so as long as the
external representations are compatible this isn't a good argument
for a separate /32 type.
The space issue might be something to think about. But I'm inclined
to think that we should build in IPv6 support from the get-go, rather
than have to add it later. We ought to try to be ahead of the curve
not behind it. So it's gonna be more than 4 bytes/entry anyway.
Would it make sense to use atttypmod to distinguish several different
subtypes of CIDR? "4 bytes", "4 bytes + mask", "6 bytes", "6 bytes
+ mask" seem like interesting possibilities.
regards, tom lane
On Tue, 21 Jul 1998, The Hermit Hacker wrote:
> On Mon, 20 Jul 1998, Paul A Vixie wrote:
>
> > > I like INET too. It is up to you.
> >
> > How do folks feel about polymorphism between IPv4 and IPv6? Should we (a)
> > make it work (either by making internal_length=10 or going variable length)
> > or (b) just make this thing IPv4 only and take care of IPv6 separately/later?
>
> Not sure about b, but doesn't FreeBSD (at least) already support
> IPv6? If so, I imagine that Linux does too? How much "later" are we
> talking about here?
>
> I'm sorry, but the IPv4 vs IPv6 issue hasnt' been something I've
> followed much, so don't know the differences...:(
Why not two types, cidr and cidr6? There's more than one type of int,
float, etc...
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Searchable Campground Listings http://www.camping-usa.com
"There is no outfit less entitled to lecture me about bloat
than the federal government" -- Tony Snow
==========================================================================
> On Mon, 20 Jul 1998, Paul A Vixie wrote: > > i don't see a need for a separate type for /32's; if someone enters just the > > dotted quad (198.96.119.100 for example) the "/32" will be assumed. i'd be > > willing to see the "/32" stripped off in the output function since it's a bit > > redundant -- i didn't do that but it's out of habit rather than strong belief. > > I don't see a problem with having a separate type for /32's. It doesn't > hurt anything, and it takes up less room that a CIDR. When you've got > several million records this becomes an issue. (Not from a perspective of > space, but more data requires more time to muck through during queries.) I would like one type, and we can specifiy a way of pulling out just hosts or class addresses. > > Plus, it would enable me to use my existing data without reloading. > (ignoring the fact that 6.4 will probably require this.) Yep. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> Paul A Vixie wrote: > > > I like INET too. It is up to you. > > > > How do folks feel about polymorphism between IPv4 and IPv6? Should we (a) > > make it work (either by making internal_length=10 or going variable length) > > or (b) just make this thing IPv4 only and take care of IPv6 separately/later? > > Making it IPv4 only just means we'll have to do it again later, and having > IPv6 functionality now would be good for those of us who are currently working > with IPv6 networks... Oh. OK. We do have variable-length types. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> "Matthew N. Dodd" <winter@jurai.net> writes: > > Plus, it would enable me to use my existing data without reloading. > > (ignoring the fact that 6.4 will probably require this.) > > 6.4 definitely will require a database reload, so as long as the > external representations are compatible this isn't a good argument > for a separate /32 type. > > The space issue might be something to think about. But I'm inclined > to think that we should build in IPv6 support from the get-go, rather > than have to add it later. We ought to try to be ahead of the curve > not behind it. So it's gonna be more than 4 bytes/entry anyway. > > Would it make sense to use atttypmod to distinguish several different > subtypes of CIDR? "4 bytes", "4 bytes + mask", "6 bytes", "6 bytes > + mask" seem like interesting possibilities. Yes, that is the proper way to go, though atttypmod is something on column, not on each data row. It is specified when the column is created. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> Would it make sense to use atttypmod to distinguish several different
>> subtypes of CIDR? "4 bytes", "4 bytes + mask", "6 bytes", "6 bytes
>> + mask" seem like interesting possibilities.
> Yes, that is the proper way to go, though atttypmod is something on
> column, not on each data row. It is specified when the column is
> created.
Right, that's what I had in mind. If you *know* that every entry in
your table only needs IPv4, you can specify that when making the table
and save a couple of bytes per entry.
The alternative solution is to make CIDR a variable-length type, but
I think the overhead of that would be as much or more than the possible
savings, no?
I don't know whether having multiple top-level types would be better
or worse than one type with a subtype code.
regards, tom lane
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >> Would it make sense to use atttypmod to distinguish several different
> >> subtypes of CIDR? "4 bytes", "4 bytes + mask", "6 bytes", "6 bytes
> >> + mask" seem like interesting possibilities.
>
> > Yes, that is the proper way to go, though atttypmod is something on
> > column, not on each data row. It is specified when the column is
> > created.
>
> Right, that's what I had in mind. If you *know* that every entry in
> your table only needs IPv4, you can specify that when making the table
> and save a couple of bytes per entry.
>
> The alternative solution is to make CIDR a variable-length type, but
> I think the overhead of that would be as much or more than the possible
> savings, no?
>
> I don't know whether having multiple top-level types would be better
> or worse than one type with a subtype code.
The byte size is really not an issue to me. You can do ip6 and still
put it in eight bytes. If you make it a variable-lengh type, you have
the length on each field, and that is four bytes right there, so you are
better doing eight bytes from the start.
ip4 5 btyes(4 + precision)
ip6 7 bytes(6 + precision)
If you want ip6 now, just take eight bytes and make it a fixed length.
The backend it going to round the disk storage of 5 bytes up to eight
anyway, unless the next field is int2 or char1.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
Thus spake Bruce Momjian
> > And the type is to be a 'CIDR', which is the appropriate
> > terminology for what it is...those that need it, will know what it is
> > *shrug*
>
> I use IP addresses and didn't know. I am also hoping we can allow
> storage of old and cidr types in the same type, at least superficially.
As I said in another message, the old types are simply special cases of
CIDR so it is already allowed.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
Replies to 5 messages contained below. > Date: Tue, 21 Jul 1998 10:00:03 -0400 (EDT) > From: "Matthew N. Dodd" <winter@jurai.net> > > I don't see a problem with having a separate type for /32's. It doesn't > hurt anything, and it takes up less room that a CIDR. When you've got > several million records this becomes an issue. (Not from a perspective of > space, but more data requires more time to muck through during queries.) > > Plus, it would enable me to use my existing data without reloading. > (ignoring the fact that 6.4 will probably require this.) It's a tradeoff. If one byte of prefix-length which adds 2MB of storage to a 2-million record table (which probably takes 3GB to store anyway due to the other fields and the metadata) is too much, then let's make a separate type for hosts as you suggest. But we're headed down an icky sticky path, which is separate types for IPv4 hosts, IPv4 CIDR blocks which can be hosts, IPv6 hosts, and IPv6 CIDR blocks which can be hosts. This seems too sticky and too icky for me -- I prefer polymorphism in 4GL's since I want to talk about what I mean and let the computer figure out how to represent/store it. In that sense I would argue for a variable width "int" type rather than a bunch of different "int2", "int4" etc types. (Too late, I know.) Though in the case of IPv6 I don't think enough is yet known about address formats (RFC 1884 was for example just rewritten, and I'm not sure the IETF is done messing with that stuff given what I know about the DNAME plans) and so I'd argue that putting the address family into the internal representation and then not supporting anything but IPv4 at this time -- basically what the implementation I posted here two days ago does -- is the practical short term thing to do. > Date: Tue, 21 Jul 1998 10:35:21 -0400 > From: Nick Bastin <nbastin@rbbsystems.com> > > Making it IPv4 only just means we'll have to do it again later, and having > IPv6 functionality now would be good for those of us who are currently > working with IPv6 networks... That's either an argument for implementing an IPv6 type immediately, or an argument for polymorphism in a single AF-independent type. Can you be more specific? My view of IPv6, as expressed above, is "let's leave room in the type's internal representation but otherwise not worry about IPv6 right now." > From: Bruce Momjian <maillist@candle.pha.pa.us> > Date: Tue, 21 Jul 1998 10:40:58 -0400 (EDT) > > I say stick with IPv4 at this point. We can always change it in future > upgrades. dump/reload will handle any changes in the internal format. As expressed above, I agree with this viewpoint. > We can call it INET now, and change it to INET4/INET6 if we decide we > want separate types for the two address types. I can live with this approach, choking up no hairballs at all. > > That means "192.7.34.21/24" is either (a) a syntax error or (b) equivilent > > to "192.7.34/24". > > How do we store the netmask? Is that a separate field? There is no netmask. In CIDR notation the "/nn" suffix just tells you how to interpret the mantissa if it does not fall on an octet boundary. Therefore "204.152.184/21" is three bits shorter than "204.152.184". There is no provision in the CIDR universe for expressing a "netmask" since that would be a mantissa longer than its "prefix". CIDR is all about prefixes, it's not just a shorthand for aggregating an <address,netmask> pair. I can see why you'd like to be able to use it as an aggregated <address,netmask> pair but (a) that's not what it is and (b) this is not the time or place to invent something new in the CIDR field -- that sort of work would and should begin with an Internet Draft in the appropriate working group. > > Can we wait and see if someone misses / asks for these before we make them? > > Suppose I want to retrieve only 'host' addresses. How do we do that? There's no way to do that with the type I posted here the other day. There'd be no problem adding the function you proposed, like LENGTH(cidr), and then doing a SELECT...WHERE using that function -- but it would be an iterative search, there's no way I can think of for the query optimizer to build up the implicit trie you'd need to go directly to all prefixes of a certain length. > > Perhaps we ought to make new type insertion easier since it's so cool? > > Yep, it is cool. When the code is installed as a standard part of the > backend, you have more facilities to install types. There are examples > of many other types in the include/catalog/*.h files, so you just pick > one and duplicate the proper partsTrying to do that with an SQL > statement is really messy, particularly because the standard types DON'T > use SQL to install themselves. You also must specify unique OIDs for > these new entries. Also, the terminology is not something that many > people are familiar with, so a lot of it is having the user understand > what they need to do. The manuals do a pretty good job. If you have > any specific ideas, or things that got you confused that we should > clearify, please let us know. From a marketing standpoint, if user defined types are one of PostgreSQL's unique features, then they ought to be so easy to add that we have hundreds of them in ./contrib at any given time. This means that most of the standard ones should be installed using whatever technology is used to install new contributed ones: because it will force that installation process to become easier. There's no reason to avoid new syntax for this since it's a new thing -- if we can do CREATE FUNCTION and CREATE TYPE and CREATE OPERATOR then why not CREATE BINDING to just associate various functions, by name rather than by OID, with the magic index operator slots for that type? Or even extending the CREATE TYPE syntax to bind the indexing functions to the type at the time of its creation? > From: Bruce Momjian <maillist@candle.pha.pa.us> > Date: Tue, 21 Jul 1998 10:45:45 -0400 (EDT) > > It is already being worked on by one of the ip_and_mac developers. He > is merging the types. We need him to work on it because he understands > PostgreSQL better. Sounds great, I'll wait to hear from that person (if my help is needed.) > Again, it is being worked on. I don't think Paul wants to get into > installing in into the main tree. It is quite a job. We may need to > increase the max system oid to get us more available oids. Actually I would have dived into this and thought it was fun, but doubtless I would not have done as good or as quick a job as the ip_and_mac guys. > > And the type is to be a 'CIDR', which is the appropriate > > terminology for what it is...those that need it, will know what it is > > *shrug* > > I use IP addresses and didn't know. I am also hoping we can allow > storage of old and cidr types in the same type, at least superficially. Sounds like conclusive evidence for calling this the INET type rather than the CIDR type. And if someone wants to make an INET32 type to account for the case of millions of host-only (no prefix length needed) fields, so be it. > From: Bruce Momjian <maillist@candle.pha.pa.us> > Date: Tue, 21 Jul 1998 11:01:10 -0400 (EDT) > > > I don't see a problem with having a separate type for /32's. It doesn't > > hurt anything, and it takes up less room that a CIDR. When you've got > > several million records this becomes an issue. (Not from a perspective of > > space, but more data requires more time to muck through during queries.) > > I would like one type, and we can specifiy a way of pulling out just > hosts or class addresses. I also lean significantly in the direction of a single type for all of IPv4 rather than a separate INET32 type. > > Plus, it would enable me to use my existing data without reloading. > > (ignoring the fact that 6.4 will probably require this.) I think there's no way to justify permanent engineering decisions on the basis of a single reload operation or the avoidance of one. > Yep. > From: Bruce Momjian <maillist@candle.pha.pa.us> > Date: Tue, 21 Jul 1998 11:02:11 -0400 (EDT) > > > Making it IPv4 only just means we'll have to do it again later, and having > > IPv6 functionality now would be good for those of us who are currently > > working with IPv6 networks... > > Oh. OK. We do have variable-length types. My question is, do those types have an internal framing format with an outer length and an inner opaque structure, or does each one have a "length" accessor to which an opaque structure is passed? In the former case, we'll be burning more space on a length indicator even though the address family and prefix length are in the opaque part of the structure. In the latter case, there's no big deal at all since given the address family and prefix length, an accessor can tell the type system the size of a particular datum.
On Tue, 21 Jul 1998, Paul A Vixie wrote:
> > > And the type is to be a 'CIDR', which is the appropriate
> > > terminology for what it is...those that need it, will know what it is
> > > *shrug*
> >
> > I use IP addresses and didn't know. I am also hoping we can allow
> > storage of old and cidr types in the same type, at least superficially.
I believe this underscores Marc's point, which is all the more reason to
call it what it is, "cidr" not some other term only used to schmooze
someone's ignorance to the proper terminology.
> Sounds like conclusive evidence for calling this the INET type rather than
> the CIDR type. And if someone wants to make an INET32 type to account for
> the case of millions of host-only (no prefix length needed) fields, so be it.
You were right the first time Paul, stick with cidr.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Searchable Campground Listings http://www.camping-usa.com
"There is no outfit less entitled to lecture me about bloat
than the federal government" -- Tony Snow
==========================================================================
> My question is, do those types have an internal framing format with an outer > length and an inner opaque structure, or does each one have a "length" > accessor to which an opaque structure is passed? In the former case, we'll > be burning more space on a length indicator even though the address family > and prefix length are in the opaque part of the structure. In the latter > case, there's no big deal at all since given the address family and prefix > length, an accessor can tell the type system the size of a particular datum. The length is on every field. atttypmod is a fixed value stored in the attribute table, and is used to modify the handling of all value in that column. We currently only use it for char(3)/varchar(30), etc. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> On Tue, 21 Jul 1998, Paul A Vixie wrote:
>
> > > > And the type is to be a 'CIDR', which is the appropriate
> > > > terminology for what it is...those that need it, will know what it is
> > > > *shrug*
> > >
> > > I use IP addresses and didn't know. I am also hoping we can allow
> > > storage of old and cidr types in the same type, at least superficially.
>
> I believe this underscores Marc's point, which is all the more reason to
> call it what it is, "cidr" not some other term only used to schmooze
> someone's ignorance to the proper terminology.
>
> > Sounds like conclusive evidence for calling this the INET type rather than
> > the CIDR type. And if someone wants to make an INET32 type to account for
> > the case of millions of host-only (no prefix length needed) fields, so be it.
>
> You were right the first time Paul, stick with cidr.
I think we have to be able to store both old-style and cidr-style
addresses for several reasons:
we have current users of ip_and_mac
some people don't use cidr yet
we need to be able to store netmasks too, which aren't cidr
So a generic INET type is clearer, and will support both address types.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
Thus spake Bruce Momjian
> I think we have to be able to store both old-style and cidr-style
> addresses for several reasons:
I must be missing something. Can you suggest a classfull network
designation that doesn't fit into the CIDR system? For example,
what's the difference between the following networks?
Class "A" network 10
10.0.0.0 mask 255.0.0.0
10.0.0.0/8
Don't they all refer to exactly the same thing? If you subnet that
network into 256 equal subnets you might have this instead.
Class "B" network 10.42
10.42.0.0 mask 255.255.0.0
10.42.0.0/16
Now that first one is an invalid designation in the old classfull system
so it doesn't matter if you can specify it. Under CIDR, however, that
subnet is perfectly valid (except that that particular range won't route
on the Internet) and the designations work. So why not store the old
classfull networks in the cidr type? They fit just fine.
> we have current users of ip_and_mac
I don't know enough about this type but other than a different name, how
can expanding the range of allowable values limit them?
> some people don't use cidr yet
Name one. They may not know what it is called but very little software
or hardware still supports classes. Do Macs still force the distinction?
In any case, class networks fit in CIDR.
> we need to be able to store netmasks too, which aren't cidr
Now this is an issue but it is the same issue as hosts. Netmasks
can also be designated as /32. However, if all you want to store
is the netmask, just use int. The range is 0 to 32.
> So a generic INET type is clearer, and will support both address types.
I have no particular problem with calling it INET instead of CIDR if
that gets the type into the system but let's be clear that either way,
any host and netmask combination can be stored whether it fits in
the old class system or not.
Perhaps there is an underlying difference of assumptions about what
the actual type is. Let me take a stab at defining it (without
naming it) and see if we're all on the same bus.
I see the underlying data type storing two things, a host address
(which can hold an IPv4 or IPv6 IP) and a netmask which can be
stored as a small int, 8 bits is plenty. The input function would
read IP numbers as follows (I'm making some of this up as I go.)
x.x.x.x/y IP x.x.x.x with masklen y
x.x.x.x:y.y.y.y IP x.x.x.x with masklen determined by examining
y.y.y.y raising an exception if it is an invalid
mask (defined as all ones followed by all zeroes)
x.x.x.x IP x.x.x.x masklen of 32
The output functions would print in a standard way, possibly allowing
alternate representations like we do for money. Also, there would
be functions to extract the host, the network or the netmask.
Is this close to what everyone thinks or are we talking about completely
different things?
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
Just voicing enthusiasm for the "cidr" thread: Bruce is right on when he refers to this as "KILLER APP" - PostgreSQL is a great tool for running administering a network. (I contributed a couple smallish functions about a year ago to do simple address formatting and in-subnet testing.) Especially when you mix in CVS for version controlling config files and rsync+ssh for pushing them. My preference is CIDR over INET or anything else for the type name. Let's get IPv6 in while Paul is focused on us. Vixie's input is essential for keeping us On The Right Track with this thing - I'd give him 100 votes and the rest of us 1 each in all the debates. :-) A data type is much more useful if it has enough supporting functions - I too like the idea of a built-in (quasi-standard) way of extracting host and class. The easier we make the type to use, the more people will use it. I think this is just the tip of the iceberg (others have hinted at this too). PostgreSQL + CVS + rsync/ssh + apache makes one powerful net admin system, but it's a tool chest with just the nuts and bolts. As we use the new CIDR datatype, I hope we'll evolve a good, general set of tools around the network database.
On Tue, 21 Jul 1998, Tom Lane wrote:
> "Matthew N. Dodd" <winter@jurai.net> writes:
> > Plus, it would enable me to use my existing data without reloading.
> > (ignoring the fact that 6.4 will probably require this.)
>
> 6.4 definitely will require a database reload, so as long as the
> external representations are compatible this isn't a good argument
> for a separate /32 type.
>
> The space issue might be something to think about. But I'm inclined
> to think that we should build in IPv6 support from the get-go, rather
> than have to add it later. We ought to try to be ahead of the curve
> not behind it. So it's gonna be more than 4 bytes/entry anyway.
I have to agree here...being able to say we support a CIDR type is
one thing, but able to say we support IPv6 is, IMHO, a big thing...
On Tue, 21 Jul 1998, Bruce Momjian wrote:
> I think we have to be able to store both old-style and cidr-style
> addresses for several reasons:
>
> we have current users of ip_and_mac
> some people don't use cidr yet
> we need to be able to store netmasks too, which aren't cidr
>
> So a generic INET type is clearer, and will support both address types.
I do not agree ... an INET type is clearer only for those that
don't know better, so we're now promoting ignorance of proper terminology?
We have everything else 'explained' in our man pages:
char(n) character(n) fixed-length character string
varchar(n) character varying(n) variable-length character string
So, having:
cidr n/a IPv4 addressing
cidr6 n/a IPv6 addressing
Is not unreasonable...
Mis-naming it INET and INET6, IMHO, is unreasonable, since that is
not what they are...
> On Tue, 21 Jul 1998, Bruce Momjian wrote: > > > I think we have to be able to store both old-style and cidr-style > > addresses for several reasons: > > > > we have current users of ip_and_mac > > some people don't use cidr yet > > we need to be able to store netmasks too, which aren't cidr > > > > So a generic INET type is clearer, and will support both address types. > > I do not agree ... an INET type is clearer only for those that > don't know better, so we're now promoting ignorance of proper terminology? > We have everything else 'explained' in our man pages: > > char(n) character(n) fixed-length character string > varchar(n) character varying(n) variable-length character string > > So, having: > > cidr n/a IPv4 addressing > cidr6 n/a IPv6 addressing > > Is not unreasonable... > > Mis-naming it INET and INET6, IMHO, is unreasonable, since that is > not what they are... See my earlier post, and discussion with Paul. cidr is just networks, and hosts and netmasks will require non-cidr storage. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> Thus spake Bruce Momjian
> > I think we have to be able to store both old-style and cidr-style
> > addresses for several reasons:
>
> I must be missing something. Can you suggest a classfull network
> designation that doesn't fit into the CIDR system? For example,
> what's the difference between the following networks?
>
> Class "A" network 10
> 10.0.0.0 mask 255.0.0.0
> 10.0.0.0/8
>
> Don't they all refer to exactly the same thing? If you subnet that
> network into 256 equal subnets you might have this instead.
>
> Class "B" network 10.42
> 10.42.0.0 mask 255.255.0.0
> 10.42.0.0/16
>
> Now that first one is an invalid designation in the old classfull system
> so it doesn't matter if you can specify it. Under CIDR, however, that
> subnet is perfectly valid (except that that particular range won't route
> on the Internet) and the designations work. So why not store the old
> classfull networks in the cidr type? They fit just fine.
OK, let me explain what I think Paul was saying. cidr is used for
networks. You can use it for hosts by specifying /32. It is not the
same as a netmask. For example:
host 192.24.45.32
Now, this is a host address. We can say its netmask is 255.255.255.0,
or was can say it is part of network 192.24.45/24, which would allow you
compute the netmask as 255.255.255.0. The problem is that you need the
type to support cidr, hosts, and netmasks.
My idea is to internally store the new type as 8 bytes:
____ ____ ____ ____ ____ ___ ___ ____
cidr addr x . x . x . x ip6 ip6
bits len
That way, if they specify cidr bits, we store it. If they don't we make
the bits field equal -1, and print/sort appropriately. The addr len is
usually 3, but ip6 is also easy to add by making the addr len equal 6.
> > we need to be able to store netmasks too, which aren't cidr
>
> Now this is an issue but it is the same issue as hosts. Netmasks
> can also be designated as /32. However, if all you want to store
> is the netmask, just use int. The range is 0 to 32.
>
> > So a generic INET type is clearer, and will support both address types.
>
> I have no particular problem with calling it INET instead of CIDR if
> that gets the type into the system but let's be clear that either way,
> any host and netmask combination can be stored whether it fits in
> the old class system or not.
>
> Perhaps there is an underlying difference of assumptions about what
> the actual type is. Let me take a stab at defining it (without
> naming it) and see if we're all on the same bus.
>
> I see the underlying data type storing two things, a host address
> (which can hold an IPv4 or IPv6 IP) and a netmask which can be
> stored as a small int, 8 bits is plenty. The input function would
> read IP numbers as follows (I'm making some of this up as I go.)
>
> x.x.x.x/y IP x.x.x.x with masklen y
> x.x.x.x:y.y.y.y IP x.x.x.x with masklen determined by examining
> y.y.y.y raising an exception if it is an invalid
> mask (defined as all ones followed by all zeroes)
> x.x.x.x IP x.x.x.x masklen of 32
>
> The output functions would print in a standard way, possibly allowing
> alternate representations like we do for money. Also, there would
> be functions to extract the host, the network or the netmask.
>
> Is this close to what everyone thinks or are we talking about completely
> different things?
Again, not sure we want to merge address and netmask for hosts in the
same field.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
On Wed, 22 Jul 1998, Bruce Momjian wrote:
> OK, let me explain what I think Paul was saying. cidr is used for
> networks. You can use it for hosts by specifying /32. It is not the
> same as a netmask. For example:
>
> host 192.24.45.32
>
> Now, this is a host address. We can say its netmask is 255.255.255.0,
> or was can say it is part of network 192.24.45/24, which would allow you
> compute the netmask as 255.255.255.0. The problem is that you need the
> type to support cidr, hosts, and netmasks.
192.24.45.32/32 == 192.24.45.32:255.255.255.255 (single host)
192.24.45.32/30 == 192.24.45.32:255.255.255.252 (2 hosts)
192.24.45.32/26 == 192.24.45.32:255.255.255.192 (62 hosts)
Check out: http://www.min.net/netmasks.htm, it has *all* the translations
and appropriate netmasks associated with each CIDR...
Thus spake Bruce Momjian
> OK, let me explain what I think Paul was saying. cidr is used for
> networks. You can use it for hosts by specifying /32. It is not the
> same as a netmask. For example:
>
> host 192.24.45.32
Right but a netmask could be specified as 255.255.255.0/32. Better yet,
if all you want to store is a netmask in a field, use an int. Every
netmask can be specified in dotted notation or as a mask length.
> My idea is to internally store the new type as 8 bytes:
>
> ____ ____ ____ ____ ____ ___ ___ ____
> cidr addr x . x . x . x ip6 ip6
> bits len
Why bother with the addr len? Just expand it out with zeroes before
storing it.
Maybe we could make cidr bits equal to -1 if we are storing a host with
indeterminate netmask rather than setting it to 32. That allows us
to specify raw IP numbers without faking a netmask.
> Again, not sure we want to merge address and netmask for hosts in the
> same field.
Well, someone earlier suggested two different types, cidr for IPs with
network info and inet for IPs by themselves. The only argument against
that as I recall was that the cidr type would hold IPs alone as a special
case so why bother creating two different types?
To review, here, I think, are the types of data we want to store and how
I think we can handle them with the addition of a single cidr type.
IP alone can be entered as a dotted quad with no netmask. This would be
stored as if a /32 was appended (or /-1 if we want a special flag.)
IP and netmask can be entered as x.x.x.x/m or x.x.x.x:m.m.m.m. If the
former then store the IP and netmask. If the latter then convert the
dotted mask to masklen and store as the former. Raise an exception if
the dotted mask form is invalid such as 255.255.0.255.
Network alone can be stored the same as IP numbers. You need to specify
the mask length since networks can end in zeroes. Perhaps we can special
case inputs that don't have all 4 octets and apply the old class rules
but still store them like cidr addresses. There is no need to add a
flag to differentiate networks from addresses into the type since we
use the field for one or the other so we know what it is when we need
to display it. It's like using int to store both ID numbers and counts.
The database doesn't need to know the difference because we use any
particular field to store one or the other.
Netmasks alone can be stored in an int field.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
> Thus spake Bruce Momjian
> > OK, let me explain what I think Paul was saying. cidr is used for
> > networks. You can use it for hosts by specifying /32. It is not the
> > same as a netmask. For example:
> >
> > host 192.24.45.32
>
> Right but a netmask could be specified as 255.255.255.0/32. Better yet,
> if all you want to store is a netmask in a field, use an int. Every
> netmask can be specified in dotted notation or as a mask length.
But we want the int to print as a IP address, and I don't think we want
two types for IP addresses. Too messy.
>
> > My idea is to internally store the new type as 8 bytes:
> >
> > ____ ____ ____ ____ ____ ___ ___ ____
> > cidr addr x . x . x . x ip6 ip6
> > bits len
>
> Why bother with the addr len? Just expand it out with zeroes before
> storing it.
192.0.0.1 and 192.0.0.1.0.0 are different because one is IPv6, and the
other is not. We must keep that distinction stored somewhere. Might
was well use eight bytes. The padding is going to take that much in
most cases anyway, unless they use char (length of 1) or int2 after the
field.
>
> Maybe we could make cidr bits equal to -1 if we are storing a host with
> indeterminate netmask rather than setting it to 32. That allows us
> to specify raw IP numbers without faking a netmask.
Yes, that was the idea. No one wants to see a netmask of
255.255.255.0/32. I don't want to field those support e-mails.
>
> > Again, not sure we want to merge address and netmask for hosts in the
> > same field.
>
> Well, someone earlier suggested two different types, cidr for IPs with
> network info and inet for IPs by themselves. The only argument against
> that as I recall was that the cidr type would hold IPs alone as a special
> case so why bother creating two different types?
>
> To review, here, I think, are the types of data we want to store and how
> I think we can handle them with the addition of a single cidr type.
>
> IP alone can be entered as a dotted quad with no netmask. This would be
> stored as if a /32 was appended (or /-1 if we want a special flag.)
>
> IP and netmask can be entered as x.x.x.x/m or x.x.x.x:m.m.m.m. If the
> former then store the IP and netmask. If the latter then convert the
> dotted mask to masklen and store as the former. Raise an exception if
> the dotted mask form is invalid such as 255.255.0.255.
Not sure if storing both IP and netmask in the same field is wise. You
would have:
192.0.0.3/24 cidr
192.0.0.3:255.255.0.0 host/netmask
192.0.0.3 host, implied netmask A,B,C class?
192.0.0.3/32 host?
192.0.0.3/32:255.255.255.0 host?/netmask
Interesting. Comments?
>
> Network alone can be stored the same as IP numbers. You need to specify
> the mask length since networks can end in zeroes. Perhaps we can special
> case inputs that don't have all 4 octets and apply the old class rules
> but still store them like cidr addresses. There is no need to add a
> flag to differentiate networks from addresses into the type since we
> use the field for one or the other so we know what it is when we need
> to display it. It's like using int to store both ID numbers and counts.
> The database doesn't need to know the difference because we use any
> particular field to store one or the other.
Printing?
>
> Netmasks alone can be stored in an int field.
Again, we want a unified type, that makes sense to people. It must
print out properly.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
Thus spake Bruce Momjian
> > Right but a netmask could be specified as 255.255.255.0/32. Better yet,
> > if all you want to store is a netmask in a field, use an int. Every
> > netmask can be specified in dotted notation or as a mask length.
>
> But we want the int to print as a IP address, and I don't think we want
> two types for IP addresses. Too messy.
Well, sure. In that case use the first form. I can't actually think
of any case where I would need to store netmasks independently of hosts
in any case. I'm just pointing out alternate ways to store it if you
can think of any use for such a thing.
> > Why bother with the addr len? Just expand it out with zeroes before
> > storing it.
>
> 192.0.0.1 and 192.0.0.1.0.0 are different because one is IPv6, and the
> other is not. We must keep that distinction stored somewhere. Might
> was well use eight bytes. The padding is going to take that much in
> most cases anyway, unless they use char (length of 1) or int2 after the
> field.
Yes, I am not as up on IPv6 as I would like to be. However, I thought
that IPv6 addresses were IPv4 addresses with extra octets *pre*pended.
Anyway, I suspect that either way the IPv6 addresses would have non
zero bits added so zeroes in the extra bits could be the flag for IPv4
addresses.
Hmm. How do we handle the different sized netmask lengths?
> > Maybe we could make cidr bits equal to -1 if we are storing a host with
> > indeterminate netmask rather than setting it to 32. That allows us
> > to specify raw IP numbers without faking a netmask.
>
> Yes, that was the idea. No one wants to see a netmask of
> 255.255.255.0/32. I don't want to field those support e-mails.
Again, storing netmasks themselves seems so anomalous that I do tend
to not worry to much about it. Normally if we are interested in a
netmask we are also interested in the host IP so we would store
something like "192.3.4.5/24" and, if we need the netmask, use the
netmask function.
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
and perhaps;
class('192.3.4.5/24::cidr') == C
classnet('192.3.4.5/24::cidr') == 192.3.4
> Not sure if storing both IP and netmask in the same field is wise. You
> would have:
I thought that that was the idea to begin with.
> 192.0.0.3/24 cidr
Right.
> 192.0.0.3:255.255.0.0 host/netmask
Converted internally to 192.0.0.3:/16
> 192.0.0.3 host, implied netmask A,B,C class?
Letting this convert automatically to a C class may not be what was
desired. Better to specify the netmask. You may be subnetting it
or even supernetting it.
> 192.0.0.3/32 host?
I would suggest that 192.0.0.3 should be the same thing unless we have
a mask len of -1 to signal indeterminate mask length in which case
192.0.0.3 gets converted internally to 192.0.0.3/-1. Further, printing
a cidr with mask len of 32 (or -1) should print as if the host function
were called, that is don't print the network info in such cases.
> 192.0.0.3/32:255.255.255.0 host?/netmask
But 192.0.0.3/24 or 192.0.0.3:255.255.255.0 gives all the information
that you need.
> > to display it. It's like using int to store both ID numbers and counts.
> > The database doesn't need to know the difference because we use any
> > particular field to store one or the other.
>
> Printing?
You mean printing netmasks? As I said, it seems to me that netmasks will
always be paired with a host or network but perhaps we can set up the
function table so that netmask on an integer type converts to a netmask
in the form you suggest. That would be the truly oo way to do it.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
> I thought that that was the idea to begin with.
>
> > 192.0.0.3/24 cidr
> Right.
>
> > 192.0.0.3:255.255.0.0 host/netmask
> Converted internally to 192.0.0.3:/16
This is a problem. Suppose you have:
192.0.0.0:255.255.255.0
This is a host with netmask, while:
192.0.0.0/24
is a network address. Paul?
>
> > 192.0.0.3 host, implied netmask A,B,C class?
> Letting this convert automatically to a C class may not be what was
> desired. Better to specify the netmask. You may be subnetting it
> or even supernetting it.
>
> > 192.0.0.3/32 host?
> I would suggest that 192.0.0.3 should be the same thing unless we have
> a mask len of -1 to signal indeterminate mask length in which case
> 192.0.0.3 gets converted internally to 192.0.0.3/-1. Further, printing
> a cidr with mask len of 32 (or -1) should print as if the host function
> were called, that is don't print the network info in such cases.
Yep.
>
> > 192.0.0.3/32:255.255.255.0 host?/netmask
> But 192.0.0.3/24 or 192.0.0.3:255.255.255.0 gives all the information
> that you need.
See example above. You use the 3 here to know it is a host, because the
IP address extens past the netmask, but what if they are zeros?
> You mean printing netmasks? As I said, it seems to me that netmasks will
> always be paired with a host or network but perhaps we can set up the
> function table so that netmask on an integer type converts to a netmask
> in the form you suggest. That would be the truly oo way to do it.
Certainly we could, but it seems nice to have one type just for ip-type
stuff.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
> OK, let me explain what I think Paul was saying. cidr is used for > networks. You can use it for hosts by specifying /32. It is not the > same as a netmask. For example: > > host 192.24.45.32 > > Now, this is a host address. We can say its netmask is 255.255.255.0, > or was can say it is part of network 192.24.45/24, which would allow you > compute the netmask as 255.255.255.0. The problem is that you need the > type to support cidr, hosts, and netmasks. in that case "hosts" and "netmasks" are completely unrelated to "cidr"'s and no design should try to cover all three similar-sounding-but-different needs. > My idea is to internally store the new type as 8 bytes: > > ____ ____ ____ ____ ____ ___ ___ ____ > cidr addr x . x . x . x ip6 ip6 > bits len > > That way, if they specify cidr bits, we store it. If they don't we make > the bits field equal -1, and print/sort appropriately. The addr len is > usually 3, but ip6 is also easy to add by making the addr len equal 6. ouch! the cidr i posted has an address family. there was a reason for that.
Thus spake Bruce Momjian
> > > 192.0.0.3:255.255.0.0 host/netmask
> > Converted internally to 192.0.0.3:/16
>
> This is a problem. Suppose you have:
>
> 192.0.0.0:255.255.255.0
>
> This is a host with netmask, while:
>
> 192.0.0.0/24
>
> is a network address. Paul?
I believe that these two representations refer to the same thing. Whether
that thing is a network or an address depends on the application. Either
the column is being used to store networks or hosts. That's what I was
getting at with my previous analogy with int types. An int could hold
ordinal numbers like IDs or it could hold quantities. We don't need
the data type to store which. The application knows and we don't store
ID codes and counts in the same column. The same with IP numbers. We
decide in any particular application whether a column is a list of hosts
or a list of networks and we then populate it.
I do like the idea of using attypmod to define the form of the type.
I assume we can use that to determine the output format, that is, use
it to effectively apply one of the functions to it. That makes for
a clean use of the type.
> > > 192.0.0.3/32:255.255.255.0 host?/netmask
> > But 192.0.0.3/24 or 192.0.0.3:255.255.255.0 gives all the information
> > that you need.
>
> See example above. You use the 3 here to know it is a host, because the
> IP address extens past the netmask, but what if they are zeros?
Technically, 192.0.0.0/24 is a valid host on 192.0.0 although most
people avoid it because some older equipment doesn't handle it very
well.
> > You mean printing netmasks? As I said, it seems to me that netmasks will
> > always be paired with a host or network but perhaps we can set up the
> > function table so that netmask on an integer type converts to a netmask
> > in the form you suggest. That would be the truly oo way to do it.
>
> Certainly we could, but it seems nice to have one type just for ip-type
> stuff.
I agree. I'm just saying that we can add the netmask function to integer
as well. That gives someone the flexibility to store it either way.
However, I don't think I am going to speak to this point again until
someone can give me a single example of a requirement for storing
netmasks independent of any hosts or networks. :-)
I just thought of another useful function.
broadcast('192.3.4.5/24::cidr') == 192.3.4.255
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
Thus spake Paul A Vixie
> the cidr i posted has an address family. there was a reason for that.
I know that you posted the actual code but perhaps you can give us the
50 cent tour of what you see the type doing and what has to be stored.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
> Thus spake Bruce Momjian
> > > > 192.0.0.3:255.255.0.0 host/netmask
> > > Converted internally to 192.0.0.3:/16
> >
> > This is a problem. Suppose you have:
> >
> > 192.0.0.0:255.255.255.0
> >
> > This is a host with netmask, while:
> >
> > 192.0.0.0/24
> >
> > is a network address. Paul?
>
> I believe that these two representations refer to the same thing. Whether
> that thing is a network or an address depends on the application. Either
> the column is being used to store networks or hosts. That's what I was
> getting at with my previous analogy with int types. An int could hold
> ordinal numbers like IDs or it could hold quantities. We don't need
> the data type to store which. The application knows and we don't store
> ID codes and counts in the same column. The same with IP numbers. We
> decide in any particular application whether a column is a list of hosts
> or a list of networks and we then populate it.
>
> I do like the idea of using attypmod to define the form of the type.
> I assume we can use that to determine the output format, that is, use
> it to effectively apply one of the functions to it. That makes for
> a clean use of the type.
OK. Sounds good to me. The only problem is display. If we don't
indicate whether it is a cidr or host/netmask on column creation or
insertion, how do we display it so it makes sense? Always cidr?
>
> > > > 192.0.0.3/32:255.255.255.0 host?/netmask
> > > But 192.0.0.3/24 or 192.0.0.3:255.255.255.0 gives all the information
> > > that you need.
> >
> > See example above. You use the 3 here to know it is a host, because the
> > IP address extens past the netmask, but what if they are zeros?
>
> Technically, 192.0.0.0/24 is a valid host on 192.0.0 although most
> people avoid it because some older equipment doesn't handle it very
> well.
>
> > > You mean printing netmasks? As I said, it seems to me that netmasks will
> > > always be paired with a host or network but perhaps we can set up the
> > > function table so that netmask on an integer type converts to a netmask
> > > in the form you suggest. That would be the truly oo way to do it.
> >
> > Certainly we could, but it seems nice to have one type just for ip-type
> > stuff.
>
> I agree. I'm just saying that we can add the netmask function to integer
> as well. That gives someone the flexibility to store it either way.
> However, I don't think I am going to speak to this point again until
> someone can give me a single example of a requirement for storing
> netmasks independent of any hosts or networks. :-)
OK. Why not?
>
> I just thought of another useful function.
>
> broadcast('192.3.4.5/24::cidr') == 192.3.4.255
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
Thus spake Bruce Momjian
> > I do like the idea of using attypmod to define the form of the type.
> > I assume we can use that to determine the output format, that is, use
> > it to effectively apply one of the functions to it. That makes for
> > a clean use of the type.
>
> OK. Sounds good to me. The only problem is display. If we don't
> indicate whether it is a cidr or host/netmask on column creation or
> insertion, how do we display it so it makes sense? Always cidr?
Well, I guess we just decide on a default format if it is not defined.
I think the default should be display as cidr (x.x.x.x/y) except omit
the mask length if it is 32 (or -1 if we go with that usage.) Perhaps
make one of the defined types always display cidr even in thos special
cases.
> > I agree. I'm just saying that we can add the netmask function to integer
> > as well. That gives someone the flexibility to store it either way.
> > However, I don't think I am going to speak to this point again until
> > someone can give me a single example of a requirement for storing
> > netmasks independent of any hosts or networks. :-)
>
> OK. Why not?
I'm just saying that given that there isn't any useful situation where
we might want to store netmasks alone independent of IPs, I don't see
much point in arguing how many IPs can dance on the end of a netmask.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
> Thus spake Bruce Momjian > > > I do like the idea of using attypmod to define the form of the type. > > > I assume we can use that to determine the output format, that is, use > > > it to effectively apply one of the functions to it. That makes for > > > a clean use of the type. > > > > OK. Sounds good to me. The only problem is display. If we don't > > indicate whether it is a cidr or host/netmask on column creation or > > insertion, how do we display it so it makes sense? Always cidr? > > Well, I guess we just decide on a default format if it is not defined. > I think the default should be display as cidr (x.x.x.x/y) except omit > the mask length if it is 32 (or -1 if we go with that usage.) Perhaps > make one of the defined types always display cidr even in thos special > cases. Where are we with this? I think Harouth took this on. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)