Re: [HACKERS] Open 6.4 items
От | Tom Ivar Helbekkmo |
---|---|
Тема | Re: [HACKERS] Open 6.4 items |
Дата | |
Msg-id | 86u31gyb7n.fsf@athene.nhh.no обсуждение исходный текст |
Ответ на | Open 6.4 items (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Open 6.4 items
|
Список | pgsql-hackers |
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. 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? -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
В списке pgsql-hackers по дате отправления: