From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: return value for PQbinaryTuples |
Date: | 2009-12-02 20:49:12 |
Message-ID: | b42b73150912021249y58106e13hb1775ed8ab0c86c1@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Dec 2, 2009 at 12:28 PM, Daniel Verite <daniel(at)manitou-mail(dot)org> wrote:
> Merlin Moncure wrote:
>
>> PQbinaryTuples is basically going to return whatever you passed into
>> resultformat when you executed the query (in the case of PQexec, it's
>> going to be 1 always).
>
> You mean 0 (i.e. text, not binary). And with an exception on PQexec("FETCH
> c") when c is a binary cursor. In this case the result is binary and
> PQbinaryTuples() reflects that.
quite right! I had completely forgotten about binary cursors (which
are, IMO, a total hack).
merlin
silonet=# declare test_cursor binary cursor with hold for select
1094795585::int;
DECLARE CURSOR
Time: 0.327 ms
silonet=# fetch from test_cursor;
int4
──────
AAAA
(1 row)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-12-02 21:40:05 | Re: Catastrophic changes to PostgreSQL 8.4 |
Previous Message | Rob W | 2009-12-02 20:34:49 | Query using partitioned table hangs |