Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
	by hub.org (8.9.2/8.9.1) with ESMTP id KAA45012
	for <pgsql-interfaces@postgreSQL.org>;
	Fri, 9 Apr 1999 10:02:51 -0400 (EDT)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA29434;
	Fri, 9 Apr 1999 09:59:46 -0400 (EDT)
To: StOo <stuart@comodo.net>
cc: "pgsql-interfaces@postgreSQL.org" <pgsql-interfaces@postgreSQL.org>
Subject: Re: [INTERFACES] guess what its int 64 time again. 
In-reply-to: Your message of Fri, 09 Apr 1999 11:28:24 +0000
	<370DE458.53433659@comodo.net>
Date: Fri, 09 Apr 1999 09:59:45 -0400
Message-ID: <29432.923666385@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

StOo <stuart@comodo.net> writes:
> Im trying to store 8byte information in char form on the database now
> so i can memcpy it back to a int64 when returning a tuple. But all my
> current attempts seem to fail beacuse i cant get the data stored
> correctly.im using PQexec to senddown a sql command string built by an
> sprintf , which is causing part of my problem as you have to display
> the data as %i %c %s etc and that where it shags up.

Huh?

As far as a user program goes, int8 acts just like any other integer
type: you pass it to and from libpq in the form of an ASCII digit
string.  Perhaps you're misusing sprintf --- most platforms require
either "%lld" or "%qd" to format a long long int.

Also, you should check whether 'configure' built the int8 support
at all --- the 6.4.* version of configure is not very bright about
coping with all the various variants of 64-bit-int support on different
platforms.  (6.5 is much smarter.)  Does the int8 regression test pass
for you?

			regards, tom lane