I am confused by your report. I assume AMD's still have 32-bit ints, so
it seems it should match the size of int4. Can you try using aint as a
'long' and using '%ld' to print it and see if that helps? Are you using
some compile flag to force 64-bit ints? If so,try using an int8 in the
query and that should work.
---------------------------------------------------------------------------
Mariano Reingart wrote:
> Hi, I recently moved a simple application from a 32bit Intel to a new AMD64
> server (migrated from Postgres 7.2 to 8.1.2 and LibPqEasy 3.0.4), running
> Slamd64 (Slackware port to the AMD64). Everything compiled just fine but the
> applicattion didn't work as expected.
> When I look into the tables (with psql) I see strange values in int4 columns
> like ( 16777216, 402653184, 1124073472, ...) instead of normal ones (1, 24,
> 67)
> Looking at application logs I found that libpqeasy is returning bad values
> in fetch( &int4 ) functions.
> Thinking that my code is wrong, I run pginsert example from libpgeasy and it
> didn't work either.
> Using text cursors (not binary) and atoi() solved the problem.
>
> Here is a sample code to reproduce the bug, adapted from
> /libpgeasy-3.0.4/examples/pginsert.c:
>
> #include <stdio.h>
> #include <unistd.h>
> #include "libpq-fe.h"
> #include "libpgeasy.h"
>
> int main(void) {
> int aint;
> char astring[1024];
>
> connectdb("dbname=fichadas");
> on_error_stop();
>
>
> doquery("BEGIN WORK");
> doquery("CREATE TABLE testfetch(aint int4)");
> doquery("INSERT INTO testfetch (aint) VALUES ( 1 )");
>
>
> /* this will print a strange number like 16777216 instead of 1: */
>
> doquery("DECLARE c_testfetch BINARY CURSOR FOR SELECT aint FROM
> testfetch WHERE aint=1");
> doquery("FETCH ALL IN c_testfetch");
>
> fetch(&aint);
> printf("aint=%d\n",aint);
>
>
> /* this will print a correct value: */
>
> doquery("DECLARE c2_testfetch CURSOR FOR SELECT aint FROM testfetch
> WHERE aint=1");
> doquery("FETCH ALL IN c2_testfetch");
>
> fetch(astring);
> printf("atoi(astring)=%d\n",atoi(astring));
>
> return 0;
> }
>
> /* ------------------------------- */
>
> gcc -o test1 test1.c -lpgeasy
>
> Output:
>
> aint=16777216
> atoi(astring)=1
>
> Hope this helps,
> Regards,
> Mariano Reingart
>
>
> ---------------------------(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
>
-- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com
+ If your life is a hard drive, Christ can be your backup. +
