Re: Summary: what to do about INET/CIDR

* Peter Eisentraut <peter_e@gmx.net> [001105 07:08]:
> Tom Lane writes:
> 
> > Peter Eisentraut <peter_e@gmx.net> writes:
> > > A separate function for formatting output seems necessary, but
> > > if we don't reach an agreement though, it ought to work to cast
> > > CIDR to INET to get all four octets, no?
> > 
> > Uh, weren't you one of the people objecting to relying on
> > cidr-to-inet casts to control formatting?
> 
> I didn't like the use of the to-text casts to control formatting,
> but if an existing cast would "just handle it", then why not?

> 
> > > I think the typecast-to-text representation of CIDR should be
> > > visually the same as the normal representation.
> > 
> > Well, we need *some* way to extract a representation like
> > "w.x.y.z/n".  If you don't like text() as the name of that
> > formatting function, suggest another name...
> 
> all_octets(cidr)::text maybe?
Personally, I just want a way, guaranteed to work, to get all 4 octets
printed out for both CIDR and INET types.  If I need to cast to INET,
that's fine.  We also need to make sure that we can print all the
pieces out as well (masklen, broadcast, netmask, network). 

I really would like to see this resolved for 7.1, as I have a number
of apps that need to interface with NON-techies, and we need to print
out all 4 octets, as well as netmasks, etc.  PostgreSQL is the perfect
DB for the backend BECAUSE of the inet/cidr types.  Yes, I could write
convoluted PHP code to print out the stuff, but why should I when the
DB has all the information in a nice compact form, and a SELECT
statement could handle it? 

I do understand the philosophical problems, but we really are very
close.  Can we promise that we'll get this ironed out for 7.1? 

Thanks.

-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org US Mail: 1905
Steamboat Springs Drive, Garland, TX 75044-6749