libpq and Binary Data Formats - Mailing list pgsql-hackers

First of all, apologies if this was not meant to be a feedback/wishlist mailing list.<br /><br />Binary formats in
libpqhas been (probably) a long issue (refer to the listings below) and I want to express my hope that the next
revisionof PostgreSQL would have better support for binary data types in libpq. I am in no doubt that those binary vs.
textdebates sprouted because of PostgreSQL's (or rather libpq's) ambiguity when it comes to binary data support. One
instanceis the documentation itself: it didn't really say (correct me if I'm wrong) that binary data is poorly/not
supportedand that textual data is preferred. Moreover, those ambiguities are only cleared up in mailing
lists/irc/forumswhich make it seem that the arguments for text data is just an excuse to not have proper support for
binarydata ( e.x. C:"Elephant doesn't support Hammer!" P: "You don't really need Hammer (we don't support it yet), you
cando it with Screwdriver."). This is not meant to be a binary vs. text post so I'll reserve my comments for them.
Nevertheless,they each have their own advantages and disadvantages especially when it comes to strongly typed languages
thatneither shouldn't be ignored. <br /><br />I am well-aware of the problems associated with binary formats and
backward/forwardcompatibility: <a
href="http://archives.postgresql.org/pgsql-hackers/1999-08/msg00374.php">http://archives.postgresql.org/pgsql-hackers/1999-08/msg00374.php
</a>but nevertheless, that shouldn't stop PostgreSQL/libpq's hardworking developers from coming up with a solution. The
earlinglink showed the interest of using CORBA to handle PostgreSQL objects but I belive that it's an overkill and
wouldlike to propose using ASN.1 instead. However, what's important is not really the binary/text representation. If we
lookagain the the list below, not everyone need binary formats just for speed and efficiency, rather, they need it to
beable to easily manipulate data. In other words, the interfaces to extract data is also important. <br /><br />Best
wishes,<br/>Wil<br clear="all" /><br />NOTES/History of Posts:<br /><br />1: "Query regarding PostgreSQL date/time
binaryformat for libpq" <<a href="http://archives.postgresql.org/pgsql-interfaces/2007-01/msg00040.php">
http://archives.postgresql.org/pgsql-interfaces/2007-01/msg00040.php</a>>One of the many (clueless) individuals who
wantsto get the binary format of the date/time struct (I know that there's a way to do this be converting the time to
epochusing extract(epoch from time) to convert it to somthing akin to time_t) <br />2. "Bytea network traffic: binary
vstext result format" <<a
href="http://archives.postgresql.org/pgsql-interfaces/2007-06/msg00000.php">http://archives.postgresql.org/pgsql-interfaces/2007-06/msg00000.php
</a>>One of the many Binary vs. Text debates.<br />3. "How do you convert PostgreSQL internal binary field to C
datatypes"<<a
href="http://archives.postgresql.org/pgsql-interfaces/2007-05/msg00046.php">http://archives.postgresql.org/pgsql-interfaces/2007-05/msg00046.php
</a>>An individual disgruntled because of the "half baked C API" of PostgreSQL. Although he may be wrong in some or
manyaspects, he has a point with regards to the binary format support. Moreover, he is probably one of the many
individualswho are disappointed on PostgreSQL because of this. <br />4. "Array handling in libpq" <<a
href="http://archives.postgresql.org/pgsql-interfaces/2007-01/msg00027.php">http://archives.postgresql.org/pgsql-interfaces/2007-01/msg00027.php</a>>
Oneof the common scenarios for the "need" of a binary format (or rather, a better interface): arrays. Also, the reply
ofthis is one of the many/redundant assurances that the overhead of text is minimal. <br />5. "libpq PQexecParams and
arrays"<<a
href="http://archives.postgresql.org/pgsql-interfaces/2006-06/msg00008.php">http://archives.postgresql.org/pgsql-interfaces/2006-06/msg00008.php</a>>
Anotherone of those array issues. This time, the poster/s have expressed that the documentation for binary formats is
"poorlydocumented :-(" <br />6. "PQgetvalue failed to return column value for non-text data in binary format" <<a
href="http://archives.postgresql.org/pgsql-interfaces/2007-05/msg00045.php">http://archives.postgresql.org/pgsql-interfaces/2007-05/msg00045.php
</a>>Another issue about binary formats paired with the assurance (again) that the overhead of using text is
minimal.<br/>-- <br />(<_<)(>_>)(>_<)(<.<)(>.>)(>.<)<br />Life is too short for
dial-up.