Re: New cast between inet/cidr and bytea
От | Zoltan Boszormenyi |
---|---|
Тема | Re: New cast between inet/cidr and bytea |
Дата | |
Msg-id | 465E5DC4.9050501@cybertec.at обсуждение исходный текст |
Ответ на | Re: New cast between inet/cidr and bytea (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: New cast between inet/cidr and bytea
|
Список | pgsql-hackers |
Bruce Momjian írta: > Zoltan Boszormenyi wrote: > >> Hi, >> >> we at Cybertec have developed cast functions in C between >> inet/cidr <-> bytea for a client and we would like to submit it. >> >> This is how it works: >> - IPv4 inet/cidr value will return 4 bytes if the netmask covers all 32 >> bits. >> It returns 5 bytes if the netmask is shorter than 32 bits. >> - Similarly for IPv6, 12[+1] bytes is returned. >> - 4, 5, 12 or 13 bytes long bytea values are converted >> to an inet/cidr value, the 5th or 13th byte is range-checked >> to be a valid netmask value. >> >> What are the requirements for it to be accepted >> as a core cast function or as a contrib module? >> > > You discuss it on the hackers list. That's what I am trying to. > Have you read the developer's FAQ? > Not yet in its entireness. > What is the use case for such a cast? > e.g.: # select '192.168.0.1'::inet::bytea; bytea ------------------\300\250\000\001 (1 row) # select '192.168.0.0/24'::inet::bytea; bytea ----------------------\300\250\000\000\030 (1 row) # select decode('\\300\\250\\000\\001', 'escape')::inet; decode -------------192.168.0.1 (1 row) # select decode('\\300\\250\\000\\000\\030', 'escape')::inet; decode ----------------192.168.0.2/24 (1 row) Similarly for IPv6 addresses. The application doesn't want to parse the textual IP address when all the parsing and checking intelligence is already there in the inet/cidr type checks. The reverse when you pass in bytes is only a logical extension. -- ---------------------------------- Zoltán Böszörményi Cybertec Geschwinde & Schönig GmbH http://www.postgresql.at/
В списке pgsql-hackers по дате отправления: