Re: inet/cidr type comparisons

On Mon, 11 Jun 2001, Tom Lane wrote:

> 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.
Well, since I'm making an indexqual clause, I do need a valid pg_proc id
there. 

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)

> > 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?

Yeah, same reason I want to have text-to-varchar-with-masklen, it really
sucks having to separate masklen and host, then aggregating them back
again...At any case, I think it has to be public due to above reasoning
(function id for planner)

> > 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.
OK

> 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').
Sounds ok, but I'd like to have network_set_masklen then to change masklen
without having to break up the value again...

Thanks again.

-alex