Re: Summary: what to do about INET/CIDR

Поиск
Список
Период
Сортировка
От Larry Rosenman
Тема Re: Summary: what to do about INET/CIDR
Дата
Msg-id 20001027151636.A17018@lerami.lerctr.org
обсуждение исходный текст
Ответ на Re: Summary: what to do about INET/CIDR  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
* Tom Lane <tgl@sss.pgh.pa.us> [001027 15:14]:
> Alex Pilosov <alex@pilosoft.com> writes:
> > Also, I agree with Larry that cidr _must_ be printed with 4 octets in
> > them, whether they are 0 or not. (i.e. it should print 207.158.72.0/24)
> 
> > This is the standard way of specifying addresses in all network equipment.
> > RFC specifies that, just the library that we use doesn't (yes, it is from
> > Vixie, but it doesn't make it RFC-compliant)
> 
> Somehow, I am more inclined to believe Vixie's opinion on this than
> either yours or Larry's ;-)
> 
> If you think there is an RFC that demands the above behavior and not
> what Vixie recommended to us, let's see chapter and verse.
> 
> FWIW, the direction we seem to be converging in is that INET will always
> print all four octets.  Maybe the answer for you is to use INET, rather
> than to try to persuade us that you understand CIDR notation better than
> Vixie does...
What I need is a way to convince PG to print all 4 octets from a CIDR
type.  I *WANT* the safety of the CIDR type for blocks of addresses,
but need to be able to print all 4 octets out for NON-TECHIES. 

LER
> 
>             regards, tom lane
-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Summary: what to do about INET/CIDR
Следующее
От: Guy Fraser
Дата:
Сообщение: Can't import date using copy