Re: Re: postgres - development of inet/cidr

From: Jakub Bartosz Bielecki <J(dot)B(dot)Bielecki(at)elka(dot)pw(dot)edu(dot)pl>
To: Sevo Stille <sevo(at)ip23(dot)net>
Cc: Jakub Bartosz Bielecki <J(dot)B(dot)Bielecki(at)elka(dot)pw(dot)edu(dot)pl>, pgsql-hackers(at)PostgreSQL(dot)org
Subject: Re: Re: postgres - development of inet/cidr
Date: 2000-07-06 12:52:17
Message-ID: Pine.SOL.4.21.0007061354040.20142-100000@elektron.elka.pw.edu.pl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 5 Jul 2000, Sevo Stille wrote:
>
> > > "select '10.0.0.1/27'::cidr << '10.0.0.2/27'::inet;" ERROR
> >
> > Currently it's not an error... There is no way (and no reason) to
> > distinguish between INET and CIDR.
>
> Yes, there is. CIDR is defined as the network 10.0.0.1 & /27, while INET
> is defined as host 10.0.0.1 within network 10.0.0.1 & /27. You can do
> almost every network and host calculation both in CIDR and INET, but
> you need implicit knowledge for it.

I was talking about *current* implementation of INET/CIDR (which IMHO
is very ill).
There is INET for users that want simply to store IP's and don't care
about all the technical jargon.
There is CIDR for advanced users who want to store network data.

Currently these 2 types are handled by 1 implementation, moreover despite
INET netmask and CIDR prefix-length are something completely different,
both are stored in the same field of inet structure (yuck).

At the moment it works fine. But that's only a hack.
I guess the purpose was to prevent duplication of code... Blah...

> > select '10.0.0.0/27'::inet << '10.0.0.2/27'::inet; -- FALSE
>
> Nope. If the right hand side is automatically propagated to a network,
> it is true. If not, the above IMHO should better raise an error, as a
> host can never contain a host.
>
> > select '10.0.0.0/27'::inet <<= '10.0.0.2/27'::inet; -- TRUE
>
> Well, you might argue that a host could contain-or-equal a host, but as
> only the equals part could ever be true, that is a redundant operator
> without any meaning beyond equals, and accordingly it should not be
> valid for that case.
>
> > > "select '10.0.0.1/27'::inet > '10.0.0.2/27'::cidr;"
> > It should be (and is!) true... Since second argument is
> > really '10.0.0.0/27'.
>
> Yes, but that does not make it any truer. CIDR 10.0.0.0/27 is
> definitively not 10.0.0.0 but [10.0.0.0 .. 10.0.0.31].

Same as above... You are perfectly right.

Everything works until user starts messing with _both_ INET and CIDR
at the same time.

The possible solution is:
- inhibit cidr-to-inet cast (and maybe also inet-to-cidr, because
it would throw away netmask),
- CIDR operators: > = < << >>
- INET operators: > = < (and why not & | if it would be useful???)
functions: cidr network(inet); // '10.0.0.0/27'
text host(inet); // '10.0.0.1'
int masklen(inet); // 27
- write an usable manual.

Comments?
I *might* work on it if I find some spare time. But it's unlikely :(

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 2000-07-06 13:07:19 Re: PostgreSQL & the BSD License
Previous Message Jan Wieck 2000-07-06 12:47:14 Re: 2nd update on TOAST