Adding ip4r to Postgresql core?

Joe Van Dyk <joe@tanga.com> 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 (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Tom Lane wrote:

Joe Van Dyk <joe@tanga.com> 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 (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Alvaro Herrera <alvherre@2ndquadrant.com> 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 (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Wed, Aug 7, 2013 at 9:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> 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.
http://www.efficito.com/learn_more.shtml

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

On Wed, Aug 7, 2013 at 9:44 PM, Tom Lane <tgl@sss.pgh.pa.us> 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 (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general