Re: Summary: what to do about INET/CIDR

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Summary: what to do about INET/CIDR
Дата
Msg-id Pine.LNX.4.21.0011050340090.775-100000@peter.localdomain
обсуждение исходный текст
Ответ на Re: Summary: what to do about INET/CIDR  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Summary: what to do about INET/CIDR  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane writes:

> 3. The function host(inet) will return a text representation of
>    just the IP part of an INET or CIDR value, eg, "127.1.0.0".
>    All four octets will always appear, the netmask will never appear.
>    (This is the same as its current behavior, I think.)

I think there was definite merit in the host() function returning inet, as
you originally proposed (if only for consistency with the proposed changes
to network() and broadcast()).

A separate function for formatting output seems necessary, but if we don't
reach an agreement though, it ought to work to cast CIDR to INET to get
all four octets, no?

> 4. A new function text(inet) will return a text representation of
>    both the IP and netmask parts of an INET or CIDR value, eg,
>    "127.1.0.0/16".  Unlike the default display conversions, all four
>    octets and the netmask length will always appear in the result.
>    Note that the system will consider this function to be a typecast,
>    so the same result can be gotten with inetval::text or
>    CAST(inetval AS text).

I think the typecast-to-text representation of CIDR should be visually the
same as the normal representation.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



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

Предыдущее
От: Larry Rosenman
Дата:
Сообщение: Re: regression failure...
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Summary: what to do about INET/CIDR