[Pypgsql-devel] [ pypgsql-Bugs-829744 ] Int8 values interpreted as int4

[SourceForge.net <no...@so...>]

Bugs item #829744, was opened at 2003-10-24 13:52
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=829744&group_id=16528

Category: PgInt8
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Int8 values interpreted as int4

Initial Comment:
Bigint values inserted from long positive integers in
the range 2**31 through 2**32 are retrieved as negative
values.  Values from 2**32 up are retrieved as value
shifted 32 bits right.  Result of running the attached
script:

V:\cinemon>bigint_problem.py
-2147483647
-2147483648
0
1

where the input values were:

		{'curr_up':2147483649L},
		{'curr_up':2147483648L},
		{'curr_up':4294967296L},
		{'curr_up':4294967297L},

PyPgSQL 2.4 Win32 binary release for Python 2.2.3
against PostgreSQL 7.3 on Win32.

The values are getting into the database fine, so it
looks like something in the database-> python
translation that's getting messed up:

V:\cinemon>psql cinemon
Welcome to psql 7.3.4, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help on internal slash commands
       \g or terminate with semicolon to execute query
       \q to quit

cinemon=# select esn,curr_up from terayon_in where
esn='someserial';
    esn     |  curr_up
------------+------------
 someserial | 2147483649
 someserial | 2147483648
 someserial | 4294967296
 someserial | 4294967297
(4 rows)
cinemon=# \d terayon_in
                        Table "public.terayon_in"
  Column   |           Type           |           
Modifiers
-----------+--------------------------+----------------------------------
 esn       | character varying        |
 curr_up   | bigint                   | default 0
 curr_down | bigint                   | default 0
...

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-10-24 16:31

Message:
Logged In: YES 
user_id=34901

Okay, this seems to fix the problem on Win2K+MSVC6 compiled
against postgresql 7.3.3 (and running against 7.3.4).  The
fix is using the _MSC_VER macro, rather than MS_WIN32 as
AFAICS this is a VC++ quirk that shouldn't be found in
GCC/Mingw32.

/* pgint8object.c line 286 */
static int int8_print(PgInt8Object *v, FILE *fp, int flags)
     /* flags -- not used but required by interface */
{
#ifdef _MSC_VER
    fprintf(fp, "%I64d", PgInt8_AS_LONGLONG(v));
#else
    fprintf(fp, "%lld", PgInt8_AS_LONGLONG(v));
#endif
    return 0;
}

static PyObject *int8_repr(PgInt8Object *v)
{
    char buf[32];
#ifdef _MSC_VER
    sprintf(buf, "%I64d", PgInt8_AS_LONGLONG(v));
#else
    sprintf(buf, "%lld", PgInt8_AS_LONGLONG(v));
#endif
    return Py_BuildValue("s", buf);
}

Enjoy,
Mike

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-10-24 16:21

Message:
Logged In: YES 
user_id=34901

The problem is in the int8_print and int8_repr
functions/methods.  MSVC++ requires the format %I64d, rather
than %lld to allow proper formatting of 64-bit integers. 
Working out how to check platform to include the
win32/msvc++ version now, I assume you've got a "vc++" flag
defined somewhere...

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-10-24 15:23

Message:
Logged In: YES 
user_id=34901

This appears to only be a problem with the libpq version of
PgInt8, if line 1843 of PgSQL is altered to read:

if 1:

so that the Python version is always used, the results come
back with the proper values.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=829744&group_id=16528