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: inet/cidr type comparisons |
Date: | 2001-06-11 21:00:34 |
Message-ID: | Pine.BSO.4.10.10106111559060.28444-100000@spider.pilosoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 11 Jun 2001, Tom Lane wrote:
> > It can't be resolved during the planning (directfunctioncall) because I do
> > want queries of a << b (b isn't a constant) to be also using the same
> > mechanism. (so far it looks like special_index_* can cope with that OK)
>
> You're mistaken ... that's not supported currently.
Augh, you are right. Well, now I have three options
a) fix match_clause_to_indexkey to use something like special_index_* for
'special' operators that can use indices in a nested loop-join.
b) add another access method to btree and muck with pg_amop (uuugh, bad
idea)
c) decide that I'm way deeper than I wanted to be already, and forget
about the idea.
Where I need a<<=b, I guess I can just use a>=network(b) and
a<next_network(b) directly.
Tom, thanks for helping me out.
I'll still follow up with set_masklen and network_text funcs.
-alex
From | Date | Subject | |
---|---|---|---|
Next Message | Reinoud van Leeuwen | 2001-06-11 22:06:07 | Re: Postgres Replication |
Previous Message | Jan Wieck | 2001-06-11 20:44:58 | Re: Re: REPLACE INTO table a la mySQL |