Andrew Chernow wrote:
> >>> This is exactly what libpqtypes solves. Not only do we handle
> >>> formatting of binary formats, we provide a level of protection from
> >>> internal format changes for libpq users. See the example here:
> >>> http://libpqtypes.esilo.com/. So, documentation of binary formats
> >>> (including network byte ordering) are not required.
> >> No, it is still required. There's not a single reference to libpqtypes
> >> in Postgres documentation, and libpqtypes isn't part of the distribution,
> >> if I understand it right.
> >
> > Agreed.
> >
>
> Correct, libpqtypes is not part of the core.
>
> What we are saying is, libpqtypes solves this problem. I don't think
> docs is the solution because that just supports the idea of libpq apps
> directly handling binary formats; which makes changing these formats
> MUCH harder in future releases. Lots of libpq apps would be dependant
> on these binary formats.
>
> By all means, documenting this is probably a good idea. I just don't
> think it solves any of the interesting problems.
Agreed that libpqtypes would solve the problem, but the odd thing to me
is that we have gotten very few requests for binary format information
since we added binary prepared parameters years ago, so is no one
actually using it?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
