Re: [HACKERS] Definitional issue for INET types

Поиск
Список
Период
Сортировка
От Sevo Stille
Тема Re: [HACKERS] Definitional issue for INET types
Дата
Msg-id 38AC1DB0.81A4677A@ip23.net
обсуждение исходный текст
Ответ на Definitional issue for INET types  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Definitional issue for INET types  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Date/time types: big change
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Almost there on column aliases