Re: Re: postgres - development of inet/cidr - Mailing list pgsql-hackers

From Jakub Bartosz Bielecki
Subject Re: Re: postgres - development of inet/cidr
Date
Msg-id Pine.SOL.4.21.0007061354040.20142-100000@elektron.elka.pw.edu.pl
Whole thread Raw
In response to Re: Re: postgres - development of inet/cidr  (Sevo Stille <sevo@ip23.net>)
List 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 :(



pgsql-hackers by date:

Previous
From: JanWieck@t-online.de (Jan Wieck)
Date:
Subject: Re: 2nd update on TOAST
Next
From: Thomas Lockhart
Date:
Subject: Re: pl/pgsql function out parameters