arrays returned in text format

Konstantin Izmailov <pgfizm@gmail.com> writes:

I'm using libpq to read array values, and I noticed that sometimes the
values are returned in Binary and sometimes - in Text format.

1. Returned in Binary format:
int formats[1] = { 1 }; // request binary format
res = PQexec(conn, "SELECT rgField FROM aTable", 1, formats);
assert(PQfformat(res, 0) == 1); // this is OK

2. Returned in Text format:
res = PQexec(conn, "SELECT ARRAY[1,2,3]", 1, formats);
assert(PQfformat(res, 0) == 1); // this fails???

Um, that is not the call signature of PQexec(), nor of any of its
variants.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Oops, I forgot to mention that we slightly modified libpq to request
resulting fields formats (since Postgres protocol v3 supports this). See
our additions in *Bold*:

PQexec(PGconn *conn, const char *query*, int resultFormatCount, const int*
resultFormats*)
{
if (!PQexecStart(conn))
return NULL;
if (!PQsendQuery(conn, query*, resultFormatCount, resultFormats*))
return NULL;
return PQexecFinish(conn, 0);
}

where PQsendQuery passes requested format in the Bind message:

/* construct the Bind message */
if (pqPutMsgStart('B', false, conn) < 0 ||
pqPuts("", conn) < 0 ||
pqPuts(""/* use unnamed statement */, conn) < 0)
goto sendFailed;

/* no parameters formats */
if (pqPutInt(0, 2, conn) < 0)
goto sendFailed;

if (pqPutInt(0, 2, conn) < 0)
goto sendFailed;

* if (pqPutInt(resultFormatCount, 2, conn) < 0) goto
sendFailed; for (i = 0; i < resultFormatCount; i++) {
if (pqPutInt(resultFormats[i], 2, conn) < 0) goto
sendFailed; }*

The above is being used for about 10 years in our variant of libpq. It
works for everything except for the case with ARRAY.

Thank you for the quick reply!

On Fri, Mar 4, 2016 at 10:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Konstantin Izmailov <pgfizm@gmail.com> writes:

Oops, I forgot to mention that we slightly modified libpq to request
resulting fields formats (since Postgres protocol v3 supports this).

Um. I'm not that excited about supporting bugs in modified variants of
PG. If you can present a test case that fails in stock community source
code, I'll be happy to take a look.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Tom, that was only a modification for the client-side libpq. The PG is
standard, we are using both 9.4 and 9.5 that were officially released.

I guess there is no standard test for the scenario. But if such test was
created (for checking the format of the returned arrays) it would fail.
Maybe I'm wrong, I'm not sure.

The only issue currently is a slow performance on parsing text
representation. Whole point of my question was why PG does not return
binary formatted field when requested (this is a feature supported in the
protocol).

On Fri, Mar 4, 2016 at 10:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Konstantin Izmailov <pgfizm@gmail.com> writes:

Whole point of my question was why PG does not return
binary formatted field when requested (this is a feature supported in the
protocol).

You haven't presented a test case demonstrating that that happens in
unmodified community source code. If it does happen, I'd be happy to look
into it, because I agree it'd be a bug. But I have other things to spend
my time on than reverse-engineering test cases out of code fragments
dependent on incompletely-described custom modifications of Postgres.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Tom, I was unable to reproduce the issue with standard libpq. Moreover, I
found why it was returned as Text. It was actually a bug in passing
resultFormats in the Bind message. Sorry for the false alert, my fault.

Thank you for the help!
Konstantin

On Fri, Mar 4, 2016 at 10:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: