Thread: binary cursor returning truncated data

On Wed, Apr 12, 2006 at 04:21:49PM +0200, Eric Mauvire wrote:
> i am trying to retrieve binary content of a bytea field (or postgis
> geometry field) with a binary cursor with PHP :
>
> $sql="BEGIN;DECLARE mycursor BINARY CURSOR FOR SELECT shape FROM $layerName; fetch all in mycursor;"
> ....pg_query...
>
> But my shape field shows only two bytes of data.

The PHP source code (ext/pgsql/pgsql.c) doesn't have any calls to
PQfformat or PQbinaryTuples so PHP appears to expect text data.
Looks like you'll have to fetch data in text format and use
pg_unescape_bytea.

Maybe the PHP developers would consider adding support for binary
data (or maybe they already have and rejected the idea; I don't
know).  Try asking on a PHP mailing list.

--
Michael Fuhr

Thank you Michael,
for that confirmation

I reported the bug to the PHP team, and they issued a patch.

I would also suggest to postgres developpers to simplify their code and go
back to SQL standards :)
That BINARY CURSOR thing should be avoided. With MySQL for instance, a
cursor will read the same way any type of data, binary or text.

Best regards,

Eric Mauvière

----- Original Message -----
From: "Michael Fuhr" <mike@fuhr.org>
To: "Eric Mauvière" <e.mauviere@geoclip.fr>
Cc: <pgsql-php@postgresql.org>
Sent: Sunday, April 16, 2006 6:39 PM
Subject: Re: [PHP] binary cursor returning truncated data


> On Wed, Apr 12, 2006 at 04:21:49PM +0200, Eric Mauvire wrote:
>> i am trying to retrieve binary content of a bytea field (or postgis
>> geometry field) with a binary cursor with PHP :
>>
>> $sql="BEGIN;DECLARE mycursor BINARY CURSOR FOR SELECT shape FROM
>> $layerName; fetch all in mycursor;"
>> ....pg_query...
>>
>> But my shape field shows only two bytes of data.
>
> The PHP source code (ext/pgsql/pgsql.c) doesn't have any calls to
> PQfformat or PQbinaryTuples so PHP appears to expect text data.
> Looks like you'll have to fetch data in text format and use
> pg_unescape_bytea.
>
> Maybe the PHP developers would consider adding support for binary
> data (or maybe they already have and rejected the idea; I don't
> know).  Try asking on a PHP mailing list.
>
> --
> Michael Fuhr
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
>
>

> for that confirmation
>
> I reported the bug to the PHP team, and they issued a patch.
>
> I would also suggest to postgres developpers to simplify their code and
> go back to SQL standards :)
> That BINARY CURSOR thing should be avoided. With MySQL for instance, a
> cursor will read the same way any type of data, binary or text.

I think you're rather confused.  The BINARY CURSOR is for emitted binary
data, not reading it.  If you declare a normal cursor over a binary
(bytea) field, you will get its text representation quite happily.

Chris

Hello Christopher,

i simply want to retrieve the content of a binary field in a Postgresql
table, and use that information in a PHP script.
That binary field contains binary information that must be read with PHP
binary functions (unpack).

The current way : POSTGRES cursor -> text version of the binary field in
PHP -> conversion back to a binary string with pg_unescape_bytea
is tedious and brings performance issues.

best regards,

Eric Mauvière

----- Original Message -----
From: "Christopher Kings-Lynne" <chris.kings-lynne@calorieking.com>
To: "Eric Mauvière" <e.mauviere@geoclip.fr>
Cc: <pgsql-php@postgresql.org>
Sent: Tuesday, April 18, 2006 10:28 AM
Subject: Re: [PHP] binary cursor returning truncated data


>> for that confirmation
>>
>> I reported the bug to the PHP team, and they issued a patch.
>>
>> I would also suggest to postgres developpers to simplify their code and
>> go back to SQL standards :)
>> That BINARY CURSOR thing should be avoided. With MySQL for instance, a
>> cursor will read the same way any type of data, binary or text.
>
> I think you're rather confused.  The BINARY CURSOR is for emitted binary
> data, not reading it.  If you declare a normal cursor over a binary
> (bytea) field, you will get its text representation quite happily.
>
> Chris
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
>

Is this issue still open?

Some guys say me that they experience similar troubles and this may
prevent them from migrating from OneBigWellKnownDBMS to Postgres.

On 4/18/06, Eric Mauvière <e.mauviere@geoclip.fr> wrote:
> Hello Christopher,
>
> i simply want to retrieve the content of a binary field in a Postgresql
> table, and use that information in a PHP script.
> That binary field contains binary information that must be read with PHP
> binary functions (unpack).
>
> The current way : POSTGRES cursor -> text version of the binary field in
> PHP -> conversion back to a binary string with pg_unescape_bytea
> is tedious and brings performance issues.
>
> best regards,
>
> Eric Mauvière
>
> ----- Original Message -----
> From: "Christopher Kings-Lynne" <chris.kings-lynne@calorieking.com>
> To: "Eric Mauvière" <e.mauviere@geoclip.fr>
> Cc: <pgsql-php@postgresql.org>
> Sent: Tuesday, April 18, 2006 10:28 AM
> Subject: Re: [PHP] binary cursor returning truncated data
>
>
> >> for that confirmation
> >>
> >> I reported the bug to the PHP team, and they issued a patch.
> >>
> >> I would also suggest to postgres developpers to simplify their code and
> >> go back to SQL standards :)
> >> That BINARY CURSOR thing should be avoided. With MySQL for instance, a
> >> cursor will read the same way any type of data, binary or text.
> >
> > I think you're rather confused.  The BINARY CURSOR is for emitted binary
> > data, not reading it.  If you declare a normal cursor over a binary
> > (bytea) field, you will get its text representation quite happily.
> >
> > Chris
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: don't forget to increase your free space map settings
> >
> >
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>


--
Best regards,
Nikolay