Thus spake Bruce Momjian
> > > so shall i test the inet_cidr_ functions and punt them on in?
> >
> > Ok, before I have a reality shift, the inet_cidr_ functions are simply
> > the original inet_net_ functions renamed, right?
> >
> > I so hate it when the universe does that stuttering thing.
>
> Just a clarification. If you have function that can be called with
> either type, you can put two entries in pg_proc(or I can :-) ), and that
> way the one function can take two types as parameters. Allows use to
> maintain the type easier, and less bloat.
My idea is to add a flag to the inet structure that specifies whether
the object is a cidr or an inet. Then every function checks that to
decide what action to perform (which might be to raise an exception,
trying to apply the host function to a cidr type for example) with
one exception, the input function. I see this as the functions to
do input.
inet *
inet_common_in(char *src, int flag);
This takes the input string and a flag that says whether a cidr or
an inet is being input. It pallocs the structure, sets the flag and
performs the conversion based the type. returns the inet pointer.
inet *
inet_net_in(char *src)
{ return inet_common_in(src, 0);
}
inet *
inet_cidr_in(char *src)
{ return inet_common_in(src, 1);
}
However, let's get the two types in right now with two separate groups
of functions and fold them after the release. It won't change the
user interface. Unless we think we can do it quickly.
In any case, maybe we can add the flag now since we figure we'll need
it later anyway.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
