Thread

Re: ecpg long int problem on alpha + fix

Adriaan Joubert <a.joubert@albourne.com> — 2001-04-04T14:47:50Z

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