Tom Lane writes:
> IIRC, a lot of the basic behavior of the inet/cidr types was designed by
> Paul Vixie (though he's not to blame for their I/O presentation).
> So I'm inclined to doubt that they're as broken as Stephen claims.
The ip4r extension's main use case is range lookups. You get an ip
Hi,
I wanted to craft an answer here and Peter nailed it before I could. I
use ip4r in a bunch of different projects and environments, it's doing a
perfect job, it's simple to use and damn efficient.
The ipv6 support is on the way, parts of it are already be in the CVS at
http://cvs.pgfoundry.or
- Цитат от Tom Lane (t...@sss.pgh.pa.us), на 02.12.2011 в 05:21 -
> Robert Haas writes:
>> On Thu, Dec 1, 2011 at 7:56 PM, Stephen Frost wrote:
>>> I don't have any particular care about if cidr has indexing support or
>>> not. I'm certainly not *against* it, except insofar as it encour
On Fri, Dec 2, 2011 at 3:42 AM, Peter Eisentraut wrote:
> - ip4 is fixed-length, so it's much faster. (Obviously, this is living
> on borrowed time. Who knows.)
Fair point.
> - Conversely, it might be considered a feature that ip4 only stores IPv4
> addresses.
True, although this can also be
* Peter Eisentraut (pete...@gmx.net) wrote:
> - ip4 really only stores a single address, not a netmask, not sometimes
> a netmask, or sometimes a range, or sometimes a network and an address,
> or whatever. That really seems like the most common use case, and no
> matter what you do with the other
On ons, 2011-11-30 at 17:56 -0500, Robert Haas wrote:
> On Wed, Nov 30, 2011 at 3:58 PM, Stephen Frost wrote:
> > Erm, isn't there a contrib type that already does all that for you..?
> > ip4r or whatever? Just saying, if you're looking for that capability..
>
> Oh, huh, good to know. Still, I'
Robert Haas writes:
> On Thu, Dec 1, 2011 at 7:56 PM, Stephen Frost wrote:
>> I don't have any particular care about if cidr has indexing support or
>> not. I'm certainly not *against* it, except insofar as it encourages
>> use of a data type that really could probably be better (by being more
>
On Thu, Dec 1, 2011 at 7:56 PM, Stephen Frost wrote:
> I don't have any particular care about if cidr has indexing support or
> not. I'm certainly not *against* it, except insofar as it encourages
> use of a data type that really could probably be better (by being more
> like ip4r..).
Not that y
* Robert Haas (robertmh...@gmail.com) wrote:
> Me neither. The ip4r type also supports ranges that aren't on
> CIDR-block boundaries, which probably isn't something that makes sense
> to incorporate into cidr. But not everyone needs that, and some
> people might also need support for ipv6 CIDR bl
On Thu, Dec 1, 2011 at 9:12 AM, wrote:
> I do not think that adding index support to a datatype classifies as
> semantic
> change that will break backward compatibility.
Me neither. The ip4r type also supports ranges that aren't on
CIDR-block boundaries, which probably isn't something that make
- Цитат от Stephen Frost (sfr...@snowman.net), на 01.12.2011 в 15:56 -
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, Nov 30, 2011 at 3:58 PM, Stephen Frost wrote:
>> > Erm, isn't there a contrib type that already does all that for you..?
>> > ip4r or whatever? Just saying, if
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Nov 30, 2011 at 3:58 PM, Stephen Frost wrote:
> > Erm, isn't there a contrib type that already does all that for you..?
> > ip4r or whatever? Just saying, if you're looking for that capability..
>
> Oh, huh, good to know. Still, I'm not sur
On Wed, Nov 30, 2011 at 3:58 PM, Stephen Frost wrote:
> Erm, isn't there a contrib type that already does all that for you..?
> ip4r or whatever? Just saying, if you're looking for that capability..
Oh, huh, good to know. Still, I'm not sure why you need to load a
separate type to get this... t
* Robert Haas (robertmh...@gmail.com) wrote:
> A CIDR address defines a range all by itself, without packing any
> other type on top. It just needs GIST support, and an indexable
> operator for "contains or is contained by"; then, you can define an
> exclusion constraint over a CIDR column to enfo
On Wed, Nov 30, 2011 at 1:08 PM, Jeff Davis wrote:
> One that I'd like to see is an IP address type, but that's complicated
> because inet and cidr support netmasks.
A CIDR address defines a range all by itself, without packing any
other type on top. It just needs GIST support, and an indexable
Jeff Davis writes:
> On Tue, 2011-11-29 at 12:01 -0500, Tom Lane wrote:
>> In particular, I don't understand why there's not a
>> standard float8range type; that seems like a pretty common case.
>> I'd have also expected to see a standard textrange type. What was
>> the rationale for leaving thes
On Tue, 2011-11-29 at 12:01 -0500, Tom Lane wrote:
> One thing that bothered me while looking at the range types patch is
> that it seemed you'd been mighty conservative about creating built-in
> range types.
During development, I didn't want to juggle the OIDs for too many range
types. That was r
One thing that bothered me while looking at the range types patch is
that it seemed you'd been mighty conservative about creating built-in
range types. In particular, I don't understand why there's not a
standard float8range type; that seems like a pretty common case.
I'd have also expected to see
18 matches
Mail list logo
