Quantcast

Adding ip4r to Postgresql core?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Adding ip4r to Postgresql core?

Joe Van Dyk
Hi,

Any chance ip4r could be an official postgresql extension? It's got a lot of advantages over the existing cidr/inet stuff.


Joe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding ip4r to Postgresql core?

Tom Lane-2
Joe Van Dyk <[hidden email]> writes:
> Any chance ip4r could be an official postgresql extension?

That's been proposed before, and rejected before, on the grounds that
since it doesn't support IPv6 its days are numbered.  That consideration
isn't getting any weaker as time passes.  If we accepted ip4r, then how
to someday make it support IPv6 would become the core project's problem;
and we have enough problems already.

                        regards, tom lane


--
Sent via pgsql-general mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding ip4r to Postgresql core?

Alvaro Herrera-9
Tom Lane wrote:
> Joe Van Dyk <[hidden email]> writes:
> > Any chance ip4r could be an official postgresql extension?
>
> That's been proposed before, and rejected before, on the grounds that
> since it doesn't support IPv6 its days are numbered.

Actually, that's not true.  Quoting from the linked readme file,

: IP4R therefore supports six distinct data types:
:
:   ip4   - a single IPv4 address
:   ip4r  - an arbitrary range of IPv4 addresses
:   ip6   - a single IPv6 address
:   ip6r  - an arbitrary range of IPv6 addresses
:   ipaddress  - a single IPv4 or IPv6 address
:   iprange    - an arbitrary range of IPv4 or IPv6 addresses

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


--
Sent via pgsql-general mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding ip4r to Postgresql core?

Tom Lane-2
Alvaro Herrera <[hidden email]> writes:
> Tom Lane wrote:
>> That's been proposed before, and rejected before, on the grounds that
>> since it doesn't support IPv6 its days are numbered.

> Actually, that's not true.

Ah, my information is obsolete.

>  Quoting from the linked readme file,
> : IP4R therefore supports six distinct data types:
> :   ip4   - a single IPv4 address
> :   ip4r  - an arbitrary range of IPv4 addresses
> :   ip6   - a single IPv6 address
> :   ip6r  - an arbitrary range of IPv6 addresses
> :   ipaddress  - a single IPv4 or IPv6 address
> :   iprange    - an arbitrary range of IPv4 or IPv6 addresses

So the obvious question today is whether this isn't duplicative of the
range datatype stuff.  IOW, why wouldn't we be better off to invent
inetrange and call it good?

                        regards, tom lane


--
Sent via pgsql-general mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding ip4r to Postgresql core?

Chris Travers-5



On Wed, Aug 7, 2013 at 9:44 PM, Tom Lane <[hidden email]> wrote:
Alvaro Herrera <[hidden email]> writes:
> Tom Lane wrote:
>> That's been proposed before, and rejected before, on the grounds that
>> since it doesn't support IPv6 its days are numbered.

> Actually, that's not true.

Ah, my information is obsolete.

As a user of ip4r, yes, we use it with ipv6 just fine. 

>  Quoting from the linked readme file,
> : IP4R therefore supports six distinct data types:
> :   ip4   - a single IPv4 address
> :   ip4r  - an arbitrary range of IPv4 addresses
> :   ip6   - a single IPv6 address
> :   ip6r  - an arbitrary range of IPv6 addresses
> :   ipaddress  - a single IPv4 or IPv6 address
> :   iprange    - an arbitrary range of IPv4 or IPv6 addresses

So the obvious question today is whether this isn't duplicative of the
range datatype stuff.  IOW, why wouldn't we be better off to invent
inetrange and call it good?

actually this misses the one area where ip4r is really helpful and that is GiST support.  If you want to have an exclusion constraint which specifies that no two cidr blocks in a table can contain eachother, you can do this easily with ip4r but it takes a lot of work without it.  iprange is mostly helpful in that area.

Our current core data types have better cross-type casting support, but the lack of GiST support (a commutable overlaps operator for example) is a really big limitation.

My vote would be to focus on GiST support instead, but otherwise ip4r would be acceptable to me.


--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding ip4r to Postgresql core?

Jeff Davis-8
On Wed, 2013-08-07 at 23:24 -0700, Chris Travers wrote:


> On Wed, Aug 7, 2013 at 9:44 PM, Tom Lane <[hidden email]> wrote:
>         So the obvious question today is whether this isn't
>         duplicative of the
>         range datatype stuff.  IOW, why wouldn't we be better off to
>         invent
>         inetrange and call it good?

INET allows a mask, and so doesn't offer an obvious total order.
Interestingly, a mask is somewhat like a range, so perhaps we could use
a range type that considers a mask to be an alternate representation of
a range. I thought about that briefly, but it seemed more likely to lead
to confusion or backwards-compatibility problems.

If we just had an IP(v4|v6) type with no mask and a total order, adding
a range type would be trivial.

> actually this misses the one area where ip4r is really helpful and
> that is GiST support.  If you want to have an exclusion constraint
> which specifies that no two cidr blocks in a table can contain
> eachother, you can do this easily with ip4r but it takes a lot of work
> without it.

A lot of work (much of it by Alexander Korotkov) has already gone into
improving range type [sp-]gist indexes. And range types go together well
with exclusion constraints. So, I'm not sure I follow how this is a
reason to use ip4r rather than a range type -- can you clarify?

Regards,
        Jeff Davis





--
Sent via pgsql-general mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Loading...