Re: Second proposal: what to do about INET/CIDR
От | Peter Eisentraut |
---|---|
Тема | Re: Second proposal: what to do about INET/CIDR |
Дата | |
Msg-id | Pine.LNX.4.21.0010281413470.763-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Second proposal: what to do about INET/CIDR (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Second proposal: what to do about INET/CIDR
|
Список | pgsql-hackers |
Tom Lane writes: > 3. We will add explicit functions cidr(inet) and inet(cidr) to force > the data type to one or the other style, thus allowing selection > of either display style. Note that cidr(inet) will raise an error > if given something with nonzeroes to the right of the netmask. Not sure if using functions that look like a cast to control output format is a good idea. The conversion inet => cidr seems most naturally left with the network() function. The other conversion is not well-defined. (You could define it in several reasonable ways, but that still doesn't make it "well".) ISTM that you'd really need some function build_inet(a cidr, b inet) returns inet, where b does not have a network and can somehow be fitted into network a. Actually, let's sign up Karel to write to_char(inet) and to_char(cidr). > But in the long run it might be better to remove the > binary-equivalence. I say kill it ASAP. I don't think there was ever a good reason for this besides implementation convenience; and the troubles it has caused are without end. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: