Re: Summary: what to do about INET/CIDR

* Peter Eisentraut <peter_e(at)gmx(dot)net> [001105 07:08]:
> Tom Lane writes:
>
> > Peter Eisentraut <peter_e(at)gmx(dot)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(at)lerctr(dot)org US Mail: 1905
Steamboat Springs Drive, Garland, TX 75044-6749