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
