Simon Riggs <si...@2ndquadrant.com> writes: > On 7 November 2012 13:08, Albe Laurenz <laurenz.a...@wien.gv.at> wrote: >> - I think that every feature of the line protocol should >> be exposed in the C API.
My recollection is that there are several things in the V3 protocol that were put there to satisfy JDBC, without any expectation that they'd necessarily be useful to libpq. So I don't buy the above argument as-is; it requires some clear use-cases for libpq. > Exposing every possible bug in ther underlying protocol isn't the best > plan though, especially when doing so complicates the API just to > support this. The fact that you couldn't think of any function names more mnemonic than "PQexecParams2" etc strongly suggests that this is mostly complication :-( The referenced thread from August doesn't strike me as sufficient justification. In the first place, that's only one request, and in the second place, that user was going through Perl DBI. I don't really foresee enough changes being made to the DBI/DBD stack to be able to use this facility effectively. The key point there (which is a deficiency the JDBC folk have already complained about) is that this design only helps you if you know *in advance of running the query* which result columns are bytea. While that's not a serious problem for applications running hard-coded queries, client-side libraries aren't going to know that unless they incur extra network round-trips to ask the server to Describe the query result. So what I think would be considerably more useful than this is some sort of session-level setting saying "please send results of such-and-such data type(s) in binary/text automatically". Not sure we can have that without a protocol break though. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers