Re: Second proposal: what to do about INET/CIDR

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

> 3. We will add explicit functions cidr(inet) and inet(cidr) to force
>    the data type to one or the other style, thus allowing selection
>    of either display style.  Note that cidr(inet) will raise an error
>    if given something with nonzeroes to the right of the netmask.

Not sure if using functions that look like a cast to control output format
is a good idea.  The conversion inet => cidr seems most naturally left
with the network() function.  The other conversion is not well-defined.  
(You could define it in several reasonable ways, but that still doesn't
make it "well".)  ISTM that you'd really need some function build_inet(a
cidr, b inet) returns inet, where b does not have a network and can
somehow be fitted into network a.

Actually, let's sign up Karel to write to_char(inet) and to_char(cidr).

> But in the long run it might be better to remove the
> binary-equivalence.

I say kill it ASAP.  I don't think there was ever a good reason for this
besides implementation convenience; and the troubles it has caused are
without end.

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



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Summary: what to do about INET/CIDR
Следующее
От: Don Baccus
Дата:
Сообщение: Re: LIMIT in DECLARE CURSOR: request for comments