> > With that in mind, can we work at having a 'cidr' type as part of
> > the overall system, vs contrib? I know that *I* would use it alot more if
> > I didn't have to think of loading it seperately...and I can think of at
> > least two of my projects that I'd use it in...
>
> me too. i'm already using it in fact. i just don't know how to make it
> indexable. having it be a standard type, with someone who knows postgres
> making it indexable, would be really great for the MAPS project and for
> some WHOIS/LDAP stuff we're doing here.
>
> > Considering that we are now up to three ppl out there that are
> > willing to work on this, I think we should be able to come up with a
> > 'consensus' as to what we are going to be considering "the standard" for
> > the base implementation?
>
> i remain ready to help anyone who promises to drive this thing. and while
> i feel that "cidr" is the right name, i don't feel it strongly enough to
> refuse to help unless that name is chosen. i need the functionality, and
> if it appears under some other name i will use it under that name.
This could clearly be a KILLER APP/TYPE for us. This is a pretty
sophisticated use of our type system. Indexing should present no
problems. We supply the comparison routines and plug them in, and the
optimizer automatically uses the indexes.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)