Re: [HACKERS] Re: inet/cidr/bind - Mailing list pgsql-hackers

From darcy@druid.net (D'Arcy J.M. Cain)
Subject Re: [HACKERS] Re: inet/cidr/bind
Date
Msg-id m0zUpro-0000emC@druid.net
Whole thread Raw
Responses Re: [HACKERS] Re: inet/cidr/bind
List pgsql-hackers
Thus spake Paul A Vixie
> if someone wants to be able to represent a host address and a netmask,
> then may i suggest that they use the same type, except they'll have to
> use two of them, one for the host address and one for the netmask.  in
> this case the prefix length would like to be enforced/implied at /32,
> and never printed.  this is not a CIDR.  it's how BIND's "inet_ntop"
> and "inet_pton" work.

If you are forcing/implying the netmask in the host type, why not just use
it for the netmask?  The point of my functions is to extract the different
parts from that.

> if someone wants to be able to represent a CIDRized host address, that
> is, a host and prefix, which means the host-part "can be" zero or non-zero,
> and the prefix might or might not be required in input or printed in output,
> then that's an entirely different thing from either of the above.  and
> while i've got the code almost ready to do that, i don't want this behaviour
> in my own target application for the original "cidr" prototype i sent in.
>
> it looks to me as though we've got three new pgsql types here.  you agree?

As far as I understand, that last is the only one we were expecting in
PostgreSQL.  So how about this?  Let's put back all of the original inet
stuff but call it cidr.  Finish your stuff and we'll put it in as the
inet type.  Personally I think we just need the latter but I would
rather have both than neither.

I just noticed that this wasn't copied to the list. I hope you don't
mind me copying this response there so that others can add their
opinions too.

--
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 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: problem with cvs ?
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] SELECT ... LIMIT (trial implementation)