Re: Summary: what to do about INET/CIDR

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Summary: what to do about INET/CIDR
Дата
Msg-id 2755.972677220@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Summary: what to do about INET/CIDR  (Larry Rosenman <ler@lerctr.org>)
Ответы Re: Summary: what to do about INET/CIDR  (Alex Pilosov <alex@pilosoft.com>)
Re: Summary: what to do about INET/CIDR  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Larry Rosenman <ler@lerctr.org> writes:
> OK, what I really meant was a way to coerce a CIDR entity to INET so 
> that host() can work with a CIDR type to print all 4 octets. 

Hm.  I don't see any really good reason why host() rejects CIDR input
in the first place.  What's wrong with producing the host address
that corresponds to extending the CIDR network address with zeroes?

> Currently you can't coerce a CIDR type to INET. 

Well you can, but it doesn't *do* anything.  One of the peculiarities
of these two types is that the cidr-vs-inet flag is actually stored
in the data value.  The type-system differentiation between CIDR and
INET is a complete no-op for everything except initial entry of a value
(ie, conversion of a text string to CIDR or INET); all the operators
that care (which is darn few ... in fact it looks like host() is the
only one!) look right at the value to see which type they've been given.
So applying a type coercion may make the type system happy, but it
doesn't do a darn thing to the bits, and thus not to the behavior of
subsequent operators either.  I have not yet figured out if that's a
good thing or a bad thing ...
        regards, tom lane


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

Предыдущее
От: Larry Rosenman
Дата:
Сообщение: (forw) Re: Summary: what to do about INET/CIDR
Следующее
От: Lamar Owen
Дата:
Сообщение: Re:RPM dependencies (Was: 7.0 vs. 7.1 (was: latest version?))