From: | Konstantin Izmailov <pgfizm(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: arrays returned in text format |
Date: | 2016-03-05 05:42:27 |
Message-ID: | CAAw-MseTO+U0js2AbbkqiX-BS-C9F6Vcwskh3hftN3+jAKKMdQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Konstantin Izmailov <pgfizm(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-03-05 05:52:13 | Re: arrays returned in text format |
Previous Message | Tom Lane | 2016-03-05 05:32:07 | Re: arrays returned in text format |