Re: Re: postgres - development of inet/cidr

Поиск
Список
Период
Сортировка
От Jakub Bartosz Bielecki
Тема Re: Re: postgres - development of inet/cidr
Дата
Msg-id Pine.SOL.4.21.0007061354040.20142-100000@elektron.elka.pw.edu.pl
обсуждение исходный текст
Ответ на Re: Re: postgres - development of inet/cidr  (Sevo Stille <sevo@ip23.net>)
Список 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 по дате отправления:

Предыдущее
От: JanWieck@t-online.de (Jan Wieck)
Дата:
Сообщение: Re: 2nd update on TOAST
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: pl/pgsql function out parameters