Thread: Adding ip4r to Postgresql core?
Hi,
Any chance ip4r could be an official postgresql extension? It's got a lot of advantages over the existing cidr/inet stuff.
Joe
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
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
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
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:Ah, my information is obsolete.
>> 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.
As a user of ip4r, yes, we use it with ipv6 just fine.
So the obvious question today is whether this isn't duplicative of the
> 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
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.
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