Обсуждение: Re: [HACKERS] New IP address datatype
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: > > 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. >
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.
> 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, Pennsylvania19026
"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