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