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

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

Functions to extract it is one thing.  What the data type can contain is
another.  I'm building a registry database of CIDRized IP delegations and
I need it to be an error to insert an element whose host-part is nonzero.
That was the launch application for the original "cidr" type I contributed,
and in the resulting hullabaloo we ended up trying to represent "hosts"
which had potential nonzero content across all 32 bits even though the
netmask was less than 32 bits long.  I can't make any good use of that in
my application.

Again, the question of whether there are functions available to build up
or tear apart these compound values is not relevant to my point here.  It's
a good idea to have such functions if the type is constructed as has been
proposed here during the recent hullabaloo.

But in my application, I need to be able to key a table to a network block,
and it is literally meaningless to have a nonzero host part or a fixed size
mantissa in that application.

Since other people want to use this type differently, I propose that we make
it into two types: INET for host addresses and CIDR for network addresses.
Both can include /## to set a netmask if folks really don't like making the
address and netmask into two adjacent columns.  But CIDR has to disallow
nonzero host-parts or it doesn't mean what I need it to mean.

PostgreSQL has an opportunity here to be the first SQL system to be able to
natively support IP registries.  There's some market share lurking in this.

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

Ok.  Will you take care of integrating both types, including indexing?  (My
inability to use the original cidr type for an index was my original problem.)

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

Actually I do mind, and had I been addressing the larger audience my note
would have been a lot clearer.  But now that we've moved the discussion here
I'm CC'ing the list on my response as well.  No harm done.