Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67]) by hub.org (8.8.8/8.8.8) with ESMTP id UAA24465 for ; Wed, 7 Oct 1998 20:12:47 -0400 (EDT) (envelope-from maillist@candle.pha.pa.us) Received: (from maillist@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id UAA15620; Wed, 7 Oct 1998 20:12:16 -0400 (EDT) From: Bruce Momjian Message-Id: <199810080012.UAA15620@candle.pha.pa.us> Subject: Re: [HACKERS] Open 6.4 items In-Reply-To: <86u31gyb7n.fsf@athene.nhh.no> from Tom Ivar Helbekkmo at "Oct 7, 1998 11:26:20 am" To: tih@nhh.no (Tom Ivar Helbekkmo) Date: Wed, 7 Oct 1998 20:12:15 -0400 (EDT) Cc: hackers@postgreSQL.org X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Bruce Momjian 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