Re: [HACKERS] Open 6.4 items

> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026