On Thu, May 8, 2008 at 12:27 PM, Bruce Momjian <bruce@[EMAIL PROTECTED]
> wrote:
> 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, do***entation 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 do***entation, 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 sup****ts 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, do***enting 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?
libpqtypes is safe to use right now if you are willing to patch libpq
yourself back to at least 8.2. back to 7.4 is possible but some
internal formats may have changes (we didn't check back that far) so
you'd have to be a little careful.
If I searched the archives, I could probably come up with several
requests for do***entation/explanations on how to use the binary
format, with at least one or two other patches to do byteswapping.
Since libpqtypes automatically parameterizes your query and handles
all the details of byteswapping, why would you ever want to do it
another way? What possible advantage would there be to ever invoking
PQexecParams manually? (PQexec has a small speed advantage for simple
queries, so that at least still has a place).
Add this to the fact that you now have a clean way to handle things
like arrays and composites without all the tedious and error prone
text parsing. I understand arguments related to code maintenance and
the like, but for libpq developers, there would never be a reason
(outside of occasional PQexec), to run a non 'params' based query
because it's faster, easier, and safer.
It's a catch-22 here...a lot of people are simply unaware of what the
postgresql binary flag is even supposed to do, since it's so poorly
do***ented. By the way, even with do***entation, any app relying on
binary formats without the protection of libpqtypes could suddenly and
spectacularly break since there is zero protection from binary format
changes.
merlin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
|
