> 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