| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alex Pilosov <alex(at)pilosoft(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PATCH] indexability of << operator for inet/cidr |
| Date: | 2001-06-14 23:03:23 |
| Message-ID: | 23099.992559803@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2001-06-14 23:05:10 | Re: [PATCH] indexability of << operator for inet/cidr |
| Previous Message | Tom Lane | 2001-06-14 22:09:23 | pg_stats view added to CVS tip |