Tom Lane wrote:
> >> Code that uses PQexecParams() binary "resultFormat", or the
> >> binary format of copy doesn't have that problem, but most
> >> client-side drivers don't do that.
>
> > And maybe they just can't realistically, because getting result
> > format in binary is exposed as an all-or-nothing choice in libpq.
>
> That's simply wrong. Read the documentation for PQexecParams and
> friends: you can specify text or binary per-column. It's COPY that
> has the only-one-column-format restriction, and RAW certainly isn't
> going to make that better.
About PQexecParams, I disagree, the parameters formats can be
specified independantly, but the not the results, which are either all
binary or all text.
Quoting the doc at
http://www.postgresql.org/docs/9.5/static/libpq-exec.html
<quote>
PGresult *PQexecParams(PGconn *conn, const char *command, int nParams, const Oid
*paramTypes, const char * const *paramValues, const int *paramLengths, const int
*paramFormats, int resultFormat);
[...]
resultFormat: Specify zero to obtain results in text format, or one to obtain results
in binary format. (There is not currently a provision to obtain different
result columns in different formats, although that is possible in the
underlying protocol.)
</quote>
For the client-side drivers that I've looked at, like these used in php
or perl, they just never use resultFormat=1.
I assume that they consider that having all values
in binary is unworkable for them, which is reasonable.
Maybe if they had a per-column choice, they wouldn't
use it anyway, but at least it would be theirs to decide
All this is only tangentially related to COPY RAW.
It's just that COPY RAW can be seen as an efficient alternative to
the single-column returning [SELECT bytea_column FROM...]
The drivers currently request this in text mode even though
it makes no sense in this particular case, and it gets measurably
annoying if the contents are big.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite