Re: [HACKERS] Re: inet/cidr/bind

> A network can certainly have a netmask.  In fact, it always does.  It
> can be implied in certain cases.  The following (if I understand Paul's
> proposal - correct me if not) show the relationships.
> 
> Input            cidr output        inet output
> =============    ================   ================
> 192.63.91.234    192.63.91.234/32    192.63.91.234/32
> 192.63.91        192.63.91/24       192.63.91.0/24
> 192.63           192.63/16          192.63.0.0/16
> 192              192/8              192.0.0.0/8
> 
> This look right to you, Paul?

no.  the last three inputs are not valid where a host address is expected.

> > If I am wrong about the above, I have one more question.  Would an
> > atttypmod setting for each column help?  What about a compile-time
> > define?
> 
> We discussed this at one point.  I think that is more useful for
> specifying output formats.  For example, 192.63.91.234/24 is identical
> to 192.63.91.234:255.255.255.0 (if we add that format) but I think
> that's 6.4++ too.  I think it would also only apply to the inet type
> but Paul should know.
> 
> > I know Paul is a big name, but are the duplicate types meaningful for
> > ordinary users, or would they prefer just one type.  If they would
> > prefer one type, we can do that, and make sure Paul gets what he wants
> > too.
> 
> I understand why Paul needs his type but I think the inet type is
> valuable too.  I think my suggestion above is a good compromise.

bigness of names doesn't matter.  applications matter.  i can see a use for
both types, but they are inherently different types.  a host that has a
netmask which can be expressed in cidr notation is one such type.  a net
that has a netmask which must be expressed in cidr notation is another such
type.  the difference comes down to "host part must be zero" for the network
type.  there are also some minor differences in the input/output formats,
since a host address always has four octets on both input and output, while
a network only prints as many octets as the cidr width specifies, and these
are the only required octets on input (though extra .0's can be specified).

> I think we are just about there.  If we go with my plan (completely
> different functionality for now and fold it later) there should be
> no API change later.  There will be code and catalogue changes but
> they should be relatively painless.

so shall i test the inet_cidr_ functions and punt them on in?