Re: [HACKERS] Definitional issue for INET types

From: Sevo Stille <sevo(at)ip23(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Definitional issue for INET types
Date: 2000-02-17 16:11:28
Message-ID: 38AC1DB0.81A4677A@ip23.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> Hmm. One way to throw the question into stark relief is to ask:
> Is '10/8' *equal to* '10.0.0.0/32', in the sense that unique indexes
> and operations like SELECT DISTINCT should consider them identical?
> Does your answer differ depending on whether you assume the values
> are of CIDR or INET type?

Well, in a CIDR context, they positively are different, '10.0.0.0/32' is
a host, and '10/8' is a network, and our application would positively
treat either entirely different. CIDR consistently works by
apply-mask-and-process.

In a INET context, the answer is not that easy, as net and mask have no
defined behaviour as a tuple. The mask will in some cases be a
independent entity, which presumably is why Paul Vixie made meaningless
net/mask combinations legal there. If INET is used to store e.g. a
Cisco wildcard value, the /xx part is meaningless - however, 10.1.2.3/8
would not be a shorthand for 10/8 then.

As far as ipmeter is concerned, we found out that INET is of no use for
us - even if there are some strange things you might do with odd
net/mask patterns, few of them follow any easily defined paradigm.
Personally, I am all for dropping INET, or for defining it to be
maskless (which could be done by forcing /32 for it).

Sevo

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-02-17 16:24:28 Re: [HACKERS] Almost there on column aliases
Previous Message Tom Lane 2000-02-17 16:08:13 Re: [HACKERS] Date/time types: big change