Re: [HACKERS] Re: hackers-digest V1 #1013 - Mailing list pgsql-hackers

Thus spake Paul A Vixie
> i would very much like inet_net_pton to not be changed in this way,

You mean inet_net_ntop, right?

> even though it's an internal server function the way postgres 6.4
> will be packaged.  there is an RFC specifying what this function does.

Are you talking about RFC2133?  That one doesn't even specify bits as
an argument so this is already different.  Is there another one I
should be looking at?

If a function is based on a standards document like this, shouldn't
we include that as a comment in the file?

Anyway, I seem to be mistaken about the whole cidr or inet type.
Based on the discussions we had earlier I am surprised by the
following.

darcy=> select '198.1.2.3/8'::inet;
?column?
--------
198/8
(1 row)

I would have expected it to print what I entered.  If the above is
correct then perhaps we still need a cidr type that behaves differently
or rename this to cidr and write a new inet type.

Here is what I thought we were talking about taken from postings in
this list back in July.

From Bruce Momjian:
> My guess is that it is going to output x.x.x.x/32, but we should supply
> a function so they can get just the IP or the mask from the type.  That
> way, people who don't want the cidr format can pull out the part they
> want.

This suggests that the whole address is stored and by default would be
output.  Are we outputting just the network part now and expecting my
functions to get the host part?

I said:
> Perhaps there is an underlying difference of assumptions about what
> the actual type is.  Let me take a stab at defining it (without
> naming it) and see if we're all on the same bus.
>
> I see the underlying data type storing two things, a host address
> (which can hold an IPv4 or IPv6 IP) and a netmask which can be
> stored as a small int, 8 bits is plenty.  The input function would
> read IP numbers as follows (I'm making some of this up as I go.)
>
>   x.x.x.x/y             IP x.x.x.x with masklen y
>   x.x.x.x:y.y.y.y       IP x.x.x.x with masklen determined by examining
>                         y.y.y.y raising an exception if it is an invalid
>                         mask (defined as all ones followed by all zeroes)
>   x.x.x.x               IP x.x.x.x masklen of 32
>
> The output functions would print in a standard way, possibly allowing
> alternate representations like we do for money.  Also, there would
> be functions to extract the host, the network or the netmask.
>
> Is this close to what everyone thinks or are we talking about completely
> different things?

No one contradicted me so I assumed that there was agreement.

From Bruce Momjian:
> That way, if they specify cidr bits, we store it.  If they don't we make
> the bits field equal -1, and print/sort appropriately.  The addr len is
> usually 3, but ip6 is also easy to add by making the addr len equal 6.

Supporting the idea of setting bits to -1 to mean an unspecified netmask.

I also checked doc/README.inet.  It seems to support what I expect
although it doesn't mention setting bits to -1.

So what do I do?  Should I redo the inet functions without using the
inet_net_* functions as described above or is the current behaviour the
one we wanted?

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