From: | Alex Pilosov <alex(at)pilosoft(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] indexability of << operator for inet/cidr |
Date: | 2001-06-15 04:35:13 |
Message-ID: | Pine.BSO.4.10.10106150033311.17529-100000@spider.pilosoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 14 Jun 2001, Tom Lane wrote:
> Alex Pilosov <alex(at)pilosoft(dot)com> writes:
> > Indexpath generated for such an expression is this:
> > (a > network(b)) and (a <= set_masklen(broadcast(b, 32)))
>
> What happens to that set_masklen thing for IPv6?
>
> If the network.c code were exporting a function that made this value,
> I'd not worry; but I don't like wiring an IPv4 assumption into code far
> away in the planner. Can't we do better here? Perhaps move the
> generation of the indexscan bound values into a subroutine in network.c?
Good point. I already rewrote it, but I am going to send it in tomorrow, I
want to resync to HEAD, since some of network.c was taken in and I want to
have a clean patch for you guys :)
Thanks
-alex
From | Date | Subject | |
---|---|---|---|
Next Message | Henshall, Stuart - WCP | 2001-06-15 09:41:37 | RE: Row Versioning, for jdbc updateable result sets |
Previous Message | Mike Mascari | 2001-06-15 01:45:00 | Re: Update on Access 97 and = NULL |