PQunescapeBytea problem--what am i doing wrong? - Mailing list pgsql-novice

From Jay G. Scott
Subject PQunescapeBytea problem--what am i doing wrong?
Date
Msg-id 200303061713.h26HDE720385@csdsun1.arlut.utexas.edu
Whole thread Raw
List pgsql-novice
Greetings,

I think I must be doing something wrong, but I can't see it.
I've tried this on Solaris 9, sparc, and Solaris 8, x86.
The tests agree:
   PQunescapeBytea doesn't return what was put into PQescapeBytea.

my code:
/*----------------------------------------------------------------------------*/
#include <stdio.h>
#include <stdlib.h>
# include <libpq-fe.h>
#include <zlib.h>
#include <time.h>
# include <string.h>
# include <sys/ddi.h>

#include "common.h"
/*----------------------------------------------------------------------------*/
int main( void )
{
unsigned char origa[60000];
size_t origlen;
unsigned char *escape;
unsigned char escapea[200000];
size_t esclen;
unsigned char *recovered;
unsigned char recovereda[70000];
size_t recovlen;
int jj;
/*----------------------------------------------------------------------------*/
/*      fake some input. */
origlen = 500;
for( jj= 0; jj< origlen; jj++ )
        {
        /* i don't really care about overflow, or even what's in here. */
        origa[jj] = '0' + jj;
        }
/*----------------------------------------------------------------------------*/
escape = PQescapeBytea( origa, origlen, & esclen );
memcpy( escapea, escape, esclen );
free( escape );

recovered = PQunescapeBytea( escapea, &recovlen );
memcpy( recovereda, recovered, recovlen );
free( recovered );
/*----------------------------------------------------------------------------*/
/*      are they even the same length? */
printf("orig len = %d\n", origlen );
printf("recovered len = %d\n", recovlen );
for( jj=0; jj < min( origlen, recovlen ); jj++)
        {
        if( origa[jj] != recovereda[jj] )
                {
                printf("first diff at %d\n",jj);
                break;
                }
        }



return 0;
}
/*----------------------------------------------------------------------------*/
/*----------------------------------------------------------------------------*/
Makefile....

hexify: hexify.c
        cc hexify.c -I/opt/include -lpq -o hexify
/*----------------------------------------------------------------------------*/
/*----------------------------------------------------------------------------*/
here's the execution:

torn> hexify
orig len = 500
recovered len = 1276
first diff at 45

my "real world" test involved a jpeg.  (i know, i know, but i wanted
to.)  there, the first diffs came at byte 676.  the point being,
it's not like it can only do 40 bytes or so, it is input dependent.

i can't believe i'm the first to encounter this, because it should
have been corrected by now.  so, what am i doing wrong?

i wound up writing something that took binary, wrote it out
as hex, and that i can recover correctly.  aaargh, it's not really
hex, but it is 16 printable characters.  i could make it real
hex easily enough, just haven't....  i'm assuming i'll get
a fix to PQ....

(i can submit my "hexify" code to the developers if they want it.
i'm just assuming the problem i'm having is something i'm doing,
not PQ(un)escapeBytea.  also, i don't know whether my hexify code
is endian dependent--it may be.  so somebody might have to fix
it anyway.)

j.

pgsql-novice by date:

Previous
From: Tom Lane
Date:
Subject: Re: ALTER TABLE DROP COLUMN
Next
From: Aspire Something
Date:
Subject: Re: [ADMIN] New Interface for Win