From: | Michael Meskes <meskes(at)postgresql(dot)org> |
---|---|
To: | Adriaan Joubert <a(dot)joubert(at)albourne(dot)com> |
Cc: | Postgresql <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ecpg long int problem on alpha + fix |
Date: | 2001-04-04 13:34:02 |
Message-ID: | 20010404153402.A4922@feivel.credativ.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 04, 2001 at 03:35:34PM +0300, Adriaan Joubert wrote:
> OK, I see. Problem is that without the fix ecpg aborts when writing to a
> table with an int8 column using valid code.
Sorry, I still don't seem to understand that. Data between ecpg and the
backend is tranfered in ascii only. What exactly happens?
> all exist on alpha and are all 64 bits, but HAVE_LONG_LONG_INT_64 is not
> defined, so ecpg cannot handle ECPGt_long_long types. It is not clear to
I see. I was under the impression that HAVE_LONG_LONG_INT_64 should be
defined if long long int is 64 bit integer which of course it is on the
alpha.
> me what the best thing is to fix here -- possibly configure needs to set
> HAVE_LONG_LONG_INT_64 (which solves the problem on alpha as well), but I
> do not know what the consequences of that are.
I would think that this is the correct solution. After all there is a
#ifdef HAVE_LONG_LONG_INT_64 in the backend as well.
Anyone else with more knowledge about HAVE_LONG_LONG_INT_64 dare to comment?
Michael
--
Michael Meskes
Michael(at)Fam-Meskes(dot)De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-04-04 13:58:19 | Re: logging is funny... |
Previous Message | Frank Byrum | 2001-04-04 13:14:39 | Re: optreset test failed in configure on Solaris 7.1RC2 |