Alex Pilosov <alex@pilosoft.com> writes:
> What I have right now is rewriting a <<= b to use index plan :
> (a >= network(b)) && ( a <= broadcast(b) )
> However, that breaks down, since (for example)
> if a=10.1.2.3/32 and b = 10.1.2.0/24, broadcast(b) will be 10.1.2.255/24,
> but 10.1.2.255/24 is considered to be less than 10.1.2.3/32...
That simply demonstrates that broadcast(b) is not the right function to
use to derive an indexscan bound. You probably want to do this the same
way that textual indexscan bounds are derived, viz for b = '10.1.2.0/24'
a >= '10.1.2.0/24' AND a < '10.1.3.0/24'
In other words, increment the network part. This is for the same
reasons that motivate the construction of indexscan limits for
"a LIKE 'abc%'" as "a >= 'abc' AND a < 'abd'".
While there may not be a user-visible function for next-network-part,
that hardly matters since the special-indexqual stuff isn't user-visible
either.
> So what I'm going to do then is to make a function set_masklen(inet|cidr,
> int4) which would take an existing address and return a new value with
> changed masklen.
There may or may not be any reason to export such a function; are there
other uses for such a thing?
> Also, I'd like to create casting functions from varchar to inet/cidr,
> since they are missing. Functions I'm writing:
Should be functions from text to inet/cidr, for consistency with the
rest of Postgres.
> varchar_inet(varchar, int4)
> varchar_cidr(varchar, int4)
> (the last two variants will take masklen as a separate argument)
And do what exactly? What if the text string specifies masklen too?
Unless this is a very common scenario, seems it's sufficient to provide
text to inet/cidr. The other can be done with the equivalent of
inet('10.1.2.3' || '/' || '32').
regards, tom lane