Re: ecpg long int problem on alpha + fix - Mailing list pgsql-hackers

From Adriaan Joubert
Subject Re: ecpg long int problem on alpha + fix
Date
Msg-id 3ACB3416.B38C5225@albourne.com
Whole thread Raw
In response to ecpg long int problem on alpha + fix  (Adriaan Joubert <a.joubert@albourne.com>)
Responses Re: ecpg long int problem on alpha + fix  (Michael Meskes <meskes@postgresql.org>)
List pgsql-hackers
Michael Meskes wrote:
> 
> 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?

This has nothing to do with the backend. ecpg itself core-dumps after
calling abort() at the end of the switch statement in typename.c, when
processing a .pgc file. As people complained to me about ecpg
core-dumping I tried to find out why and then found that it called the
abort() at the end of this switch ;-)

I have not looked at ecpg in any detail, but I expect that the types in
typename.c are derived from the host variables in some way. If we have
an int8 column in a table, we need to use a 64 bit type, i.e. a 'long
long', and as HAVE_LONG_LONG_INT_64 is not true, no such type is
compiled into the switch. As HAVE_LONG_INT_64 is defined on alpha, my
fix fixes this for alpha, and any other platform where HAVE_LONG_INT_64
is defined but not HAVE_LONG_LONG_INT_64. 

From Tom's mail I gather that it is not an option to define
HAVE_LONG_LONG_INT_64 on alpha, so I think this patch, or something
similar, is necessary.

Apologies for not being clear enough initially.

Cheers,

Adriaan


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: All's quiet ... RC3 packaging ...
Next
From: Tom Lane
Date:
Subject: Re: All's quiet ... RC3 packaging ...