Re: [HACKERS] Open 6.4 items

> > Looks good to me.  I haven't done really heavy testing yet, and I'd
> > also like to update the regression test
> 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.

It would be great if you could gin up a real regression test, since I'm
up to my eyeballs in other Postgres projects. But if you can't, or want
some help, let me know. I'd be happy to help with integration of the
test...

> > One problem though, seemingly lately introduced:  It's nice
> > to input IP addresses in various formats...
> > 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.

There is a problem, but this is not the explanation. See below...

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

What you describe as "no longer works" is actually a core dump on my
machine:

postgres=> select 'x12345678'::ipaddr;
ERROR:  could not parse "x12345678"
postgres=> select '0x12345678'::ipaddr;
pqReadData() -- backend closed the channel unexpectedly.

Any single-quote-delimited string is passed to the corresponding _in()
routine without change. So the system is not changing anything before
ipaddr_in() sees it for input. It appears that the _in() code tries to
handle strings starting with "X", but fails to do so (though I'm not
exactly sure what a correct value would look like; I would have guessed
that something like 'x12121212' might be legal, but it fails). It also
appears that the code crashes if there is a leading zero and an
otherwise hex-looking value following, even though it at least sometimes
is checking that each character is valid.

I haven't looked at it further, but the core dump feature should be a
"must-fix" and I would put the "hex input" in the same category since
the code claims to handle it but doesn't. Volunteers?

                      - Tom