Re: [HACKERS] Open 6.4 items

> Bruce Momjian <maillist@candle.pha.pa.us> writes:
>
> > test new cidr/IP address type(Tom Helbekkmo)
>
> Looks good to me.  I haven't done really heavy testing yet, and I'd
> also like to update the regression test -- what I included was just a
> very quick sequence to see that it basically worked, but we should
> have a more comprehensive test.  No great hurry there, though: for
> now, I'd say it's ready for shipping, modulo the renaming of IPADDR to
> INET, for which I'm sending a separate patch kit.

OK.  I think Thomas is adding it to the regression tests, particularly
so people can see how it works.  Your readme is now in the manual.


> One problem though, seemingly lately introduced:  It's nice to be able
> to input IP addresses in various formats, for compatibility with other
> software.  One of the common formats is a network byte order hex
> string, like 0x12345678.  Until very recently, I could check what the
> heck the actual address behind such a representation was, by going
> "select '0x12345678'::ipaddr;".  This no longer works, because the
> system now helpfully transforms the hex into a long int or something
> and then tries to treat the result as an ipaddr.  Uh-oh.
>
> The intuitively correct thing would be for the hex string to be read
> and converted as a numeric value only if the type it is being cast to
> is, indeed, numeric in nature.  In the given case, it should be up to
> ipaddr_in() to make sense of the character string.  Or what do you say?

Thomas?

--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026