New IP address datatype

I'm constructing a new type "ip4" as a unified replacement to inet and
cidr,
to hopefully relieve some of the confusion involving those types.
Would anyone be interested?

Mark

But they are the same, except for output, right? We discussed the
having a unified type, but could not figure out how to output things
properly. I recommend you see the huge discussion on the hackers list
about these types in the October/November 1998 timeframe.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <maillist@candle.pha.pa.us> writes:

I recommend you see the huge discussion on the hackers list
about these types in the October/November 1998 timeframe.

Yup ... and note that the existing types were designed partly on the
advice of Paul Vixie, who knows a thing or three about IP addressing.

regards, tom lane

I've been looking at those discussions -- my idea is to simplify
the ip network types ( and operators ) a little:

Hosts are specified as '134.67.131.10' or '134.67.131.10/32' and
display 134.67.131.10.

Subnets are specified as '134.67.131.0/24', '134.67.131/24', or
just '134.67.131', but they would display '134.67.131.0/24'.

There would be no provision for storing a host/netmask in the
same structure; it seems confusing to me anyway since you could
put the netmask in a seperate column.

Thanks,
Mark

( Sorry, I meant to post to the list the first time )
Bruce Momjian wrote:

On Mon, 31 May 1999, Tom Lane wrote:

Bruce Momjian <maillist@candle.pha.pa.us> writes:

I recommend you see the huge discussion on the hackers list
about these types in the October/November 1998 timeframe.

Yup ... and note that the existing types were designed partly on the
advice of Paul Vixie, who knows a thing or three about IP addressing.

Have to agree here...what we have now was prompted, and, in large part,
designed by Paul Vixie, and *that* was after some major discussions on the
lists concerning how to implement.

I think there would have to be some very strong arguments for changing it
now, as well as opening discussions with Paul on this...in alot of ways,
its his arena...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Thus spake Mark Volpe

I'm constructing a new type "ip4" as a unified replacement to inet and
cidr,
to hopefully relieve some of the confusion involving those types.
Would anyone be interested?

Yikes! Please be very careful. We went through a lot of work to get
it right. The fact that there are two types was a bit of a compromise
to get what everyone wanted into the system. Note that the underlying
routines are exactly the same anyway. The difference is all in the
input and output and pretty minor at that but the differences are
essential.

If you are talking about the recent discussions, we do have some issues
to resolve but making one type won't clarify the situation. I think
we are pretty sure about what to do. Someone just needs to find time
to do it.

If you found the dual types confusing, maybe the problem is in the
documentation. I am assuming from your offer that you have spent some
time studying the type and understand the point of both so perhaps
you can attack the documentation instead.

Oh, and if ip4 means IPv4, that's a step backwards. The current types
are designed to be easily extended to handle IPv6 in the same types.

-- 
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'm constructing a new type "ip4" as a unified replacement to inet and
cidr,

But they are the same, except for output, right? We discussed the

And input. Some values that are valid for inet are not valid cidr.

-- 
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 Tom Lane

Yup ... and note that the existing types were designed partly on the
advice of Paul Vixie, who knows a thing or three about IP addressing.

Speaking of which, I wonder what Paul would say about the primary key
discussion. Maybe I'll drop him a note.

-- 
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 Mark Volpe

I've been looking at those discussions -- my idea is to simplify
the ip network types ( and operators ) a little:

Hosts are specified as '134.67.131.10' or '134.67.131.10/32' and
display 134.67.131.10.

darcy=> \d x
Table    = x
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                | Length|
+----------------------------------+----------------------------------+-------+
| i                                | inet                             |   var |
| c                                | cidr                             |   var |
+----------------------------------+----------------------------------+-------+
darcy=> insert into x values ('134.67.131.0/24', '134.67.131.0/24');
INSERT 34272 1
darcy=> insert into x values ('134.67.131/24', '134.67.131/24');    
INSERT 34273 1
darcy=> insert into x values ('134.67.131', '134.67.131');      
ERROR:  could not parse "134.67.131"
darcy=> insert into x values ('134.67.131.0', '134.67.131');
INSERT 34274 1

Note how 134.67.131 is a valid cidr but not a valid inet. Now look
how they display.

darcy=> select * from x;
i |c
---------------+-------------
134.67.131.0/24|134.67.131/24
134.67.131.0/24|134.67.131/24
134.67.131.0 |134.67.131/24
(3 rows)

As inet types, all octets are displayed. In the last case, it assumes
a host and displays accordingly. Note that while cidr will accept the
old classfull syntax, it displays using proper cidr format.

Subnets are specified as '134.67.131.0/24', '134.67.131/24', or
just '134.67.131', but they would display '134.67.131.0/24'.

As an inet type. As a cidr type they should display as above. You
seem to be confusing two concepts.

There would be no provision for storing a host/netmask in the
same structure; it seems confusing to me anyway since you could
put the netmask in a seperate column.

You could and, if all you want to store is a netmask, you could store
the number of bits in an int. If, however, you want to track a network
(cidr) or a host with all it's network information (inet) then they
should be in one type. Hosts can be stored in inet simply by leaving
off the bits part.

So, if you combine the types, will the new type act like a cidr or an inet?
Personally, I wouldn't kick if a third type (host) was created just to
allow for a type that doesn't allow network information to be included.
Different input (just doesn't allow the slash) and everything else like
the inet type.

-- 
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.

"D'Arcy" "J.M." Cain <darcy@druid.net> writes:

Speaking of which, I wonder what Paul would say about the primary key
discussion. Maybe I'll drop him a note.

Good thought, if he's not reading the mailing list anymore (which seems
likely given the volume...).

I still assert that indexes need to behave the same as the comparison
operators --- but maybe the comparison operators ought to behave
differently for INET and CIDR types? It seems reasonable that
the netmask should be ignored when comparing one, but not the other...

regards, tom lane

Thus spake Mark Volpe

Hosts are specified as '134.67.131.10' or '134.67.131.10/32' and
display 134.67.131.10.

Hmm. This suggests that the example given in the recent discussion
about primary keys is bogus: 198.68.123.0/24 is never equal to
198.68.123.0/27, because they represent networks of different sizes.
If you were talking about host addresses, then the netmask would be
/32 in both cases, and so the issue doesn't arise.

I'm back to the opinion that netmask does matter in comparisons and in
indexes ... but I'd sure like to hear what Vixie has to say about it.

BTW, if we did want to make INET and CIDR have different behavior in
comparisons and indexes, that would mean having two sets of operators
listed in the system catalogs. We cannot add that as a post-6.5 patch
because it would require an initdb, which is one of the things we don't
do between major releases. If it's wrong (I'm not convinced) we must
either fix it this week or live with it till 6.6 ...

regards, tom lane

On Mon, 31 May 1999, Tom Lane wrote:

BTW, if we did want to make INET and CIDR have different behavior in
comparisons and indexes, that would mean having two sets of operators
listed in the system catalogs. We cannot add that as a post-6.5 patch
because it would require an initdb, which is one of the things we don't
do between major releases. If it's wrong (I'm not convinced) we must
either fix it this week or live with it till 6.6 ...

Live with it until 6.6...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Thus spake Tom Lane

Thus spake Mark Volpe

Hosts are specified as '134.67.131.10' or '134.67.131.10/32' and
display 134.67.131.10.

Hmm. This suggests that the example given in the recent discussion
about primary keys is bogus: 198.68.123.0/24 is never equal to
198.68.123.0/27, because they represent networks of different sizes.

I don't think it's so clear cut. For INET, the two addresses refer
to the same host but contradict each other in network details. The
INET type is primarily a host type with optional network information
added. One might even argue that 198.68.123.1/24 and 198.68.123.2/27
should not be allowed to coexist but that's probably going too far.

For the CIDR type, they refer to two different networks but they overlap.
The argument is that as a primary key they partially conflict so they
shouldn't be allowed to coexist.

If you were talking about host addresses, then the netmask would be
/32 in both cases, and so the issue doesn't arise.

Right. For the INET type the netbits defaults to /32 so it can be used
for hosts transparently.

I'm back to the opinion that netmask does matter in comparisons and in
indexes ... but I'd sure like to hear what Vixie has to say about it.

I have asked him.

BTW, if we did want to make INET and CIDR have different behavior in
comparisons and indexes, that would mean having two sets of operators
listed in the system catalogs. We cannot add that as a post-6.5 patch
because it would require an initdb, which is one of the things we don't
do between major releases. If it's wrong (I'm not convinced) we must
either fix it this week or live with it till 6.6 ...

At this point I doubt we want to start mucking with catalogues and new
operators. Fixing it to be consistent is probably doable.

And since I will never use either type as a primary key, I can live
with either decision. :-)

-- 
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 Tom Lane

Thus spake Mark Volpe

Hosts are specified as '134.67.131.10' or '134.67.131.10/32' and
display 134.67.131.10.

Hmm. This suggests that the example given in the recent discussion
about primary keys is bogus: 198.68.123.0/24 is never equal to
198.68.123.0/27, because they represent networks of different sizes.

I don't think it's so clear cut. For INET, the two addresses refer
to the same host but contradict each other in network details. The
INET type is primarily a host type with optional network information
added. One might even argue that 198.68.123.1/24 and 198.68.123.2/27
should not be allowed to coexist but that's probably going too far.

For the CIDR type, they refer to two different networks but they overlap.
The argument is that as a primary key they partially conflict so they
shouldn't be allowed to coexist.

If you were talking about host addresses, then the netmask would be
/32 in both cases, and so the issue doesn't arise.

Right. For the INET type the netbits defaults to /32 so it can be used
for hosts transparently.

I'm back to the opinion that netmask does matter in comparisons and in
indexes ... but I'd sure like to hear what Vixie has to say about it.

I have asked him.

BTW, if we did want to make INET and CIDR have different behavior in
comparisons and indexes, that would mean having two sets of operators
listed in the system catalogs. We cannot add that as a post-6.5 patch
because it would require an initdb, which is one of the things we don't
do between major releases. If it's wrong (I'm not convinced) we must
either fix it this week or live with it till 6.6 ...

At this point I doubt we want to start mucking with catalogues and new
operators. Fixing it to be consistent is probably doable.

And since I will never use either type as a primary key, I can live
with either decision. :-)

OK, but let's make a decision.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

"D'Arcy J.M. Cain" wrote:

Thus spake Mark Volpe

I've been looking at those discussions -- my idea is to simplify
the ip network types ( and operators ) a little:

Hosts are specified as '134.67.131.10' or '134.67.131.10/32' and
display 134.67.131.10.

Actually I was talking about the behavior of my "unified" type :)

If I have:

CREATE TABLE x ( i ip4 );
INSERT INTO x VALUES('10.20.30.40');
INSERT INTO x VALUES('10.20.30');
INSERT INTO x VALUES('10.20');
INSERT INTO x VALUES('10.20.30/20');

I would have:

SELECT * FROM x;
i
-------------
10.20.30.40
10.20.30.0/24
10.20.0.0/16
10.20.16.0/20

In most applications ( e.g., IP and network registration )
you would require that there be no overlapping address space,
so the above table would be illegal in a unique index. I thought
about creating two different operator sets, but that means if
you commit to one in a btree, using the other one always requires
a Seq Scan ( am I right here? ). So I used one and as a result,
the '=' operator checks if its two operands overlap ( I also
have operators for reading and coercing the masks ). Our group
uses this sort of thing and it works pretty well.
Thanks for your comments.

Mark