i completely respect postgres's need for consistency in the appearance
of these presentation formats. if they are different from bind's then
i, as a consumer of postgresql, will learn to live with those differences.
i do not, in other words, need to be convinced at all. you guys found a
format you like, and i will do everything i can to support it.
i just want the support to occur in the postgres source code rather than
in the bind source code. there is an inet_*_*.c source file in the
postgres sources which was originally a copy of bind's, but which has
been modified to produce a different output format. i (as an occasional
contributor to postgres's development) propose that it would be easier
to just import a new version of bind's inet_*_*.c file occasionally,
and even teach "./configure" to note that it's already in libc (if it is)
and if so use the libc version rather than the internal version.
this implies that the part of postgres that calls this part of bind's
library should "fix up" the return value to convert it to "postgres style."
again, i am in complete support of postgres having its own style. i just
don't think postgres should have an incompatible variant of a BIND library
function. the stylistic variance should be applied in the postgres source,
not to a copy of the BIND source.
my problem is, i don't know exactly what the stylistic difference is,
nor do i know how to "post-apply" it to the returned result from the BIND
library, nor how to change "./configure" to notice and use the LIBC
(or -lbind) version of these functions if they exist. if someone else
could take care of those deeper matters, then i would be completely happy
to integrate vadim's ipv6 changes to the INET and CIDR data types.
