Re: ecpg long int problem on alpha + fix

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 14:47:50
Message-ID: 3ACB3416.B38C5225@albourne.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 2001-04-04 14:53:22 Re: All's quiet ... RC3 packaging ...
Previous Message Thomas Lockhart 2001-04-04 14:33:27 Re: Final call for platform testing