Re: INET/CIDR types

Поиск
Список
Период
Сортировка
От darcy@druid.net (D'Arcy J.M. Cain)
Тема Re: INET/CIDR types
Дата
Msg-id m13Gngs-000AXeC@druid.net
обсуждение исходный текст
Ответ на Re: INET/CIDR types  (Larry Rosenman <ler@lerctr.org>)
Ответы RE: INET/CIDR types  ("Larry Rosenman" <ler@lerctr.org>)
Re: INET/CIDR types  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Thus spake Larry Rosenman
> The bad news is that I'm tracking CIDR blocks. 

Then there is no host part.  I would argue that if someone is getting
confused with the current output then perhaps they shouldn't be dealing
with client networks.

> If I could get a network() function to return essentially
> host()::inet for CIDR's that would work. 

There is a network function.  It returns the network.

darcy=> select network('1.2.0.0/23'::cidr);
network 
--------
1.2.0/23
(1 row)

A lot of work went into these types to make them correct.  I don't think
we should be undermining that to allow people to work with incorrect
assumptions.  If you want Micro$oft you know where to find it.

If you really must do this then store your blocks in the INET type.  It
pretty much does what you want but doesn't try to pretend to be a CIDR.


Hmmm.  I just noticed this.

darcy=> select '1.2.0.1/23'::cidr;
?column?
--------
1.2.0/23
(1 row)

Shouldn't that throw an error?

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.


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

Предыдущее
От: Philip Warner
Дата:
Сообщение: Re: pg_dump, libdump, dump API, & backend again
Следующее
От: "Larry Rosenman"
Дата:
Сообщение: RE: INET/CIDR types