From: | Adriaan Joubert <a(dot)joubert(at)albourne(dot)com> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | Postgresql <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ecpg long int problem on alpha + fix |
Date: | 2001-04-04 12:35:34 |
Message-ID: | 3ACB1516.D3B746EB@albourne.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Meskes wrote:
>
> On Tue, Apr 03, 2001 at 06:32:25PM +0300, Adriaan Joubert wrote:
> > we had a problem on Alpha that in interfaces/ecpg/lib/typename.c we
> > have
> > HAVE_LONG_INT_64 defined, but not HAVE_LONG_LONG_INT_64. Consequently no
>
> Sure since that means your long int and not your long long int is 64 bits.
>
> > code is included for long ints and typename calls *abort*. I put in a
> > few lines that check for HAVE_LONG_INT_64 and seem to generate the right
>
> Why is this needed? What you do is use "long long" as variable type for 64
> bits integer. But on the alpha you do not need "long long", just use "long
> int" instead.
>
> Or did I misunderstand something?
OK, I see. Problem is that without the fix ecpg aborts when writing to a
table with an int8 column using valid code.
long int
long long
long long int
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
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.
Cheers,
Adriaan
From | Date | Subject | |
---|---|---|---|
Next Message | Fouad Fezzi | 2001-04-04 12:46:06 | logging is funny... |
Previous Message | Michael Meskes | 2001-04-04 12:02:53 | Re: ecpg long int problem on alpha + fix |