Repair plan for inet and cidr types
От | Peter Eisentraut |
---|---|
Тема | Repair plan for inet and cidr types |
Дата | |
Msg-id | Pine.LNX.4.21.0007050118110.3542-100000@localhost.localdomain обсуждение исходный текст |
Ответы |
Re: Repair plan for inet and cidr types
Re: Repair plan for inet and cidr types Re: Repair plan for inet and cidr types |
Список | pgsql-hackers |
As we know, the inet and cidr types are still broken in several ways, amongst others input and output functions, operators, ordering. I've collected the bug reports from the last year or so from the archives. There's apparently a lack of understanding of what exactly are these types are supposed to do. Therefore, instead of addressing each bug individually, let me first state what I reconstructed as the specification of these types, and then add what is currently wrong with it. * CIDR The cidr type stores the identity of an IP _network_. A network specification is of the form 'x.x.x.x/y'. The documentation states that if y is omitted then it is constructed from the old A, B, C class scheme. So be it. In a real world network, the bits (y+1)...32 have to be zero, but the cidr type does not currently enforce this. This has been the source of bugs in the past, and no doubt the source of some confusion as well. I propose that cidr _reject_ input of the form '127.0.0.5/16'. If you think about it, this is the same as int4 rejecting 3.5 as input. * INET The inet type stores the identity of an IP _host_. A host specification is of the form 'x.x.x.x'. Optionally, the inet type also stores the identity of the network the host is in. E.g., '127.0.0.5/16' means the host 127.0.0.5 in the network 127.0/16. * Type equivalency This has also been a source of problems. I propose that cidr and inet are not made equivalent types at any level. No automatic casting either. A network and a host are not the same thing. To construct a cidr value from an inet value, you'd have to use some sort of (to be created) network() function, e.g., network('127.0.0.5/16') => '127.0/16'. IMO, there is no reasonable way to construct an inet value from a cidr value. * Operators Because the types are equivalent, the operators have also been bunched together in confusing ways. I propose that ordering operators (>, +, <) between inet and cidr be eliminated, they do not make sense. The only useful operation between cidr and inet is the << ("contains") operator. Ordering withing cidr and inet be defined in terms of their bit representation, as is the case now. The << family of operators should also be removed for the inet type -- a host cannot "contain" another host. What you probably wanted is `inet1 << network(inet2)'. Does anyone see this differently? If not, can we agree on this specification? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: