Simon Riggs <simon@2ndQuadrant.com> writes:
> On 7 November 2012 13:08, Albe Laurenz <laurenz.albe@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
