Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Open 6.4 items

From: Tom Ivar Helbekkmo <tih(at)nhh(dot)no>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: hackers(at)postgreSQL(dot)org (PostgreSQL-development)
Subject: Re: [HACKERS] Open 6.4 items
Date: 1998-10-07 09:26:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

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?

Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"

In response to


pgsql-hackers by date

Next:From: Tom Ivar HelbekkmoDate: 1998-10-07 09:28:08
Subject: Re: [HACKERS] Re: CIDR/IP types. Was: [GENERAL] big numbers
Previous:From: Bruce MomjianDate: 1998-10-07 03:20:58
Subject: Open 6.4 items

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group