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

Thus spake Bruce Momjian
> Paul, can you give the unknowledgable among us an example of what you
> want and don't want?  Thanks.

Let me take a stab at it too.

> I was assuming the type would allow these as hosts:
> 
>     192.4.13.42
>     192.4.13.42    255.255.255.0

An alternate syntax of 192.4.13.42:255.255.255.0 was proposed but won't
be implemented, at least at this time.  Maybe put it into TODO for 6.4++.
In the meantime, this should be 192.4.13.42/24.

>     192.4.13.42/32
>     192.4.13.42/32 255.255.255.0

Basically two different netmasks.  I think you mean 192.4.13.42/24 here too.

> and these are networks:
> 
>     192.63.91.234/28

This is a host in a 16 IP subnet.  As a cidr type (as proposed) this
would be invalid.  Note the 234 is 11101010b and the /28 implies a
trailing octet of 11110000b.  A valid entry would have been something
like 192.63.91.224/28.

>     192.63.91.234/28 255.255.255.128

Again, the /28 and the 255.255.255.128 are trying to specify the same
thing but they are different.  The /28 is an alternate way of saying
a netmask of 255.255.255.240.  255.255.255.128 would be /25.  Either
way, this is invalid as a cidr but valid as an inet host on a network.

> Any non-32 '/' is a network?  Can a network have a netmask?  Not sure.

Nope.  /32 is a valid network.  It's a class D in the old class system.
That's why I suggested -1 for an unspecified netmask to differentiate
it from a network of one host.

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?

> Internally, a -1 in a field indicates the user did not supply a cidr
> value(assume it is a host), or did not specify a netmask.  I thought
> this is where D'Arcy was going with this.

Close.  A -1 is only valid for the inet type, not the cidr type.  This
is because the /XX effectively specifies both the network and netmask.
Under cidr this must be specified.  Under inet it may be.  If it isn't,
or -1 is specified, -1 is stored as the bits and it is not output on
display.  This allows it to be used as a host or as a host/network
combination.  Note that there is nothing stopping you from using the
inet type to store networks too.  It's just that using cidr does the
extra error checking and outputs in the more standard network format.

> I assume we are _not_ going to use the /24 notation to specify a
> netmask, because the cidr '/' notation has never been used for that,
> right?

Well, it can be implied but I think it is OK to specify.  192.63.91 and
192.63.91/24 should be the same thing.  If the number of bits is not
32, 24, 16 or 8 you have to specify it.

> 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.

> If we can get some more rapid-fire e-mails going around, I think we can
> resolve this in the next day or two.  We have testing and documenation
> to do, and Marc at some point may pull the plug on us.

> If we can come up with one type, that is less bloat/work for me, but my
> primary goal is that we come up with a solid type/types that we aren't
> going to need to redesign in the future, causing problems for existing
> users.

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.

-- 
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.