Обсуждение: arrays returned in text format
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);res = PQexec(conn, "SELECT ARRAY[1,2,3]", 1, formats);
assert(PQfformat(res, 0) == 1); // this fails???
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
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: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);
}
/* 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;
}
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:
> 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
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
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.On Fri, Mar 4, 2016 at 10:32 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
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
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!On Fri, Mar 4, 2016 at 10:52 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