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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
