pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedLibPqEasy, binary cursor, x86-64, fetch(int4) problem?
3+ messages / 3 participants
[nested] [flat]
* LibPqEasy, binary cursor, x86-64, fetch(int4) problem?
@ 2006-02-11 23:28 Mariano Reingart <mariano@nsis.com.ar>
2006-02-12 15:53 ` Re: LibPqEasy, binary cursor, x86-64, fetch(int4) problem? Michael Fuhr <mike@fuhr.org>
2006-03-06 15:35 ` Re: LibPqEasy, binary cursor, x86-64, fetch(int4) problem? Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 2 replies; 3+ messages in thread
From: Mariano Reingart @ 2006-02-11 23:28 UTC (permalink / raw)
To: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: LibPqEasy, binary cursor, x86-64, fetch(int4) problem?
2006-02-11 23:28 LibPqEasy, binary cursor, x86-64, fetch(int4) problem? Mariano Reingart <mariano@nsis.com.ar>
@ 2006-02-12 15:53 ` Michael Fuhr <mike@fuhr.org>
1 sibling, 0 replies; 3+ messages in thread
From: Michael Fuhr @ 2006-02-12 15:53 UTC (permalink / raw)
To: Mariano Reingart <mariano@nsis.com.ar>; +Cc: pgsql-interfaces
On Sat, Feb 11, 2006 at 08:28:25PM -0300, 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)
Convert the numbers to hex and they don't look so strange:
1 = 0x01
24 = 0x18
67 = 0x43
16777216 = 0x01000000
402653184 = 0x18000000
1124073472 = 0x43000000
That ought to hint at what's happening.
--
Michael Fuhr
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: LibPqEasy, binary cursor, x86-64, fetch(int4) problem?
2006-02-11 23:28 LibPqEasy, binary cursor, x86-64, fetch(int4) problem? Mariano Reingart <mariano@nsis.com.ar>
@ 2006-03-06 15:35 ` Bruce Momjian <pgman@candle.pha.pa.us>
1 sibling, 0 replies; 3+ messages in thread
From: Bruce Momjian @ 2006-03-06 15:35 UTC (permalink / raw)
To: Mariano Reingart <mariano@nsis.com.ar>; +Cc: pgsql-interfaces
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. +
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2006-03-06 15:35 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-02-11 23:28 LibPqEasy, binary cursor, x86-64, fetch(int4) problem? Mariano Reingart <mariano@nsis.com.ar>
2006-02-12 15:53 ` Michael Fuhr <mike@fuhr.org>
2006-03-06 15:35 ` Bruce Momjian <pgman@candle.pha.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox