Skip site navigation (1) Skip section navigation (2)

Re: Why so few built-in range types?

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Jeff Davis <pgsql(at)j-davis(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why so few built-in range types?
Date: 2011-12-02 08:42:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On ons, 2011-11-30 at 17:56 -0500, Robert Haas wrote:
> On Wed, Nov 30, 2011 at 3:58 PM, Stephen Frost <sfrost(at)snowman(dot)net> 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... there's no reason why the built-in CIDR
> type couldn't support it.

A couple of reasons:

- ip4 is fixed-length, so it's much faster.  (Obviously, this is living
on borrowed time.  Who knows.)

- Conversely, it might be considered a feature that ip4 only stores IPv4

- 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 types, some stupid netmask will appear
in your output when you least expect it.

- Integrates with ip4r, which has GiST support.

- Some old-school internet gurus worked out why inet and cidr have to
behave the way they do, which no one else understands, and no one dares
to discuss, whereas ip4/ip4r are simple and appear to be built for
practical use.

Really, it's all about worse is better.

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2011-12-02 08:59:01
Subject: Re: bug of recovery?
Previous:From: Tom LaneDate: 2011-12-02 05:30:26
Subject: Re: Accounting for toast in query planner. (gin/gist indexes).

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group