X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 73E4E9DC8A7 for ; Mon, 6 Mar 2006 11:35:54 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 40982-01 for ; Mon, 6 Mar 2006 11:35:58 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from candle.pha.pa.us (candle.pha.pa.us [70.90.9.53]) by postgresql.org (Postfix) with ESMTP id 9FFE39DC81D for ; Mon, 6 Mar 2006 11:35:51 -0400 (AST) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.11.6) id k26FZpQ10019; Mon, 6 Mar 2006 10:35:51 -0500 (EST) From: Bruce Momjian Message-Id: <200603061535.k26FZpQ10019@candle.pha.pa.us> Subject: Re: LibPqEasy, binary cursor, x86-64, fetch(int4) problem? In-Reply-To: <000301c62f62$dbd72b90$0300000a@PC1> To: Mariano Reingart Date: Mon, 6 Mar 2006 10:35:51 -0500 (EST) CC: pgsql-interfaces@postgresql.org X-Mailer: ELM [version 2.4ME+ PL121 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.442 required=5 tests=[AWL=-0.058, RAZOR2_CHECK=0.5] X-Spam-Score: 0.442 X-Spam-Level: X-Archive-Number: 200603/2 X-Sequence-Number: 6058 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 > #include > #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. +