Обсуждение: CIDR/INET improvements

The TODO list contains some items concerning the CIDR/INET datatype.

* %Prevent INET cast to CIDR if the unmasked bits are not zero, or zero the bits

I added a function for this cast (which zeroes the bits) but then the
opr_sanity regression test failed because there is a cast from INET -> CIDR
but the other way round is considered to be binary compatible.

Actually both types are not binary compatible, since they have a
type component that is either 0 or 1, depending on whether it is of type
INET or CIDR.

If nobody objects, I'll send in a patch that includes a cast function for
the other way round as well.



* Allow INET + INT4 to increment the host part of the address, or throw an error on overflow

Once at it I wonder how much arithmetic these types need?
What about functions to get/set a specific byte, for example:

inet_get_byte('192.168.1.1'::inet, 0) returns 1
inet_get_byte('192.168.1.1'::inet, 1) returns 1
inet_get_byte('192.168.1.1'::inet, 2) returns 168
inet_get_byte('192.168.1.1'::inet, 3) returns 192

and inet_set_byte('192.168.1.1'::inet, 3, 128) returns '128.168.1.1'


Which other functions have been missing here in the past?


Joachim

Joachim Wieland <joe@mcknight.de> writes:
> Actually both types are not binary compatible, since they have a
> type component that is either 0 or 1, depending on whether it is of type
> INET or CIDR.

The whole question of the relationship of those types really needs to be
looked at more carefully.  We've got this schizophrenic idea that they
sometimes are the same type and sometimes are not.  ISTM that either
they are the same type (and having a bit within the data is reasonable)
or they are distinct types (in which case the bit within the data should
be redundant).  I'm not sure which is better.

I think the reason why things are as they are right now is to avoid
needing a pile of redundant-seeming pg_proc entries, eg you'd need
both abbrev(inet) and abbrev(cidr) if you were taking a hard line
about them being different types.

You can *not* just throw in a cast that removes the bit without breaking
many of those functions for the CIDR case.  For instance abbrev behaves
differently depending on the state of the bit:

regression=# select abbrev(cidr '10.1.0.0/16');abbrev
---------10.1/16
(1 row)

regression=# select abbrev(inet '10.1.0.0/16');  abbrev
-------------10.1.0.0/16
(1 row)


> What about functions to get/set a specific byte, for example:

I would vote against adding any such thing in the absence of any strong
demand for it.  I think functions that expose the underlying data just
encourage people to write IPv4-only code.  If you can't define and use
the function in a way that handles both IPv4 and IPv6, you probably
shouldn't have it.
        regards, tom lane

On Sat, Jan 07, 2006 at 12:50:23PM -0500, Tom Lane wrote:
> Joachim Wieland <joe@mcknight.de> writes:
> > Actually both types are not binary compatible, since they have a
> > type component that is either 0 or 1, depending on whether it is of type
> > INET or CIDR.

> The whole question of the relationship of those types really needs to be
> looked at more carefully.  We've got this schizophrenic idea that they
> sometimes are the same type and sometimes are not.  ISTM that either
> they are the same type (and having a bit within the data is reasonable)
> or they are distinct types (in which case the bit within the data should
> be redundant).  I'm not sure which is better.

What about doing both? ;-)

We could create a few wrapper functions that call the functions that are
there right now. That way there is no need to duplicate the code with the
actual functionality. The outside world sees different types and the
function can distinguish between both if it needs to.


Joachim