pypgsql-devel — List for discussion of pyPgSQL development.

[Pypgsql-devel] [ pypgsql-Bugs-879531 ] Does not handle select into properly

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

Bugs item #879531, was opened at 2004-01-19 10:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=879531&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Burton (bab)
Assigned to: Nobody/Anonymous (nobody)
Summary: Does not handle select into properly

Initial Comment:
(Received through the Debian BTS as #226946) 
 
There is a bug in the execute method when dealing with select 
into queries: it checks using a simple regexp if a select 
statement is about to be executed and if so it will declare a 
cursor. This does not work for select into queries, which do not 
support cursors. Unfortunately the current approach of using a 
regexp to check for exceptions does not work very well since it is 
not possible to reliable check for select into statements without 
parsing the statement. 
 
Thanks - Ben. 

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

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

[Pypgsql-devel] [ pypgsql-Bugs-863925 ] FutureWarning (negative integers and signed strings)

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

Bugs item #863925, was opened at 2003-12-22 00:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=863925&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Burton (bab)
Assigned to: Nobody/Anonymous (nobody)
Summary: FutureWarning (negative integers and signed strings)

Initial Comment:
Hi.  The following issue was reported in the Debian BTS 
(#224325): 
 
I have a python script which started to output this warning: 
 
/usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py:2644: 
FutureWarning: %u/%o/%x/%X of negative int will return a 
signed string in Python 2.4 %and up 
 
The following patch should fix it: 
 
--- python-pgsql-2.4.0.old/pyPgSQL/PgSQL.py	2003-12-22 
00:17:47.000000000 +1100 
+++ python-pgsql-2.4.0/pyPgSQL/PgSQL.py	2003-12-22 
00:19:36.000000000 +1100 
@@ -2641,7 +2641,7 @@ 
 	if name is None: 
             if isRefCursor: 
                 raise TypeError, "Reference cursor requires a name." 
-	    name = "PgSQL_%08X" % id(self) 
+	    name = "PgSQL_%08X" % long(id(self)) 
 	elif type(name) is not StringType: 
 	    raise TypeError, "Cursor name must be a string." 
 
 
Thanks - Ben. :) 

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

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

[Pypgsql-devel] [ pypgsql-Bugs-760412 ] array.py regression test fails version 2.3, linux

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

Bugs item #760412, was opened at 2003-06-25 07:23
Message generated for change (Settings changed) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=760412&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian (ian888)
>Assigned to: Billy G. Allie (ballie01)
Summary: array.py regression test fails version 2.3, linux

Initial Comment:
ia...@fo...

Using Postgress 7.3.3 and pypgsql version 2.3, I built
pypgsql on SuSE  8.2 linux.  All tests Passed except
this one.  This could be a test failure as opposed to
be a real failure.

Please investigate.  text follows:

carra:/usr/share/pypgsql/test/regression # python array.py 
....E
======================================================================
ERROR: CheckForIntInsertMultiDim (__main__.ArrayTestCases)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "array.py", line 181, in CheckForIntInsertMultiDim
    cursor.execute("insert into test(ia) values (%s)",
intlist)
  File
"/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py",
line 2956, in execute
    raise OperationalError, msg
OperationalError: ERROR:  pg_atoi: zero-length string


----------------------------------------------------------------------
Ran 5 tests in 7.217s

FAILED (errors=1)
carra:/usr/share/pypgsql/test/regression # 

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

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

[Pypgsql-devel] [ pypgsql-Bugs-855987 ] TypeCache error (invalid constructor argument)

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

Bugs item #855987, was opened at 2003-12-07 19:34
Message generated for change (Comment added) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=855987&group_id=16528

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ben Burton (bab)
Assigned to: Nobody/Anonymous (nobody)
Summary: TypeCache error (invalid constructor argument)

Initial Comment:
(Received through the Debian BTS as #221897.) 
 
Hi - there is a mistake in the TypeCache class, specifically in 
routines typecast() and handleArray().  When creating 
PgLargeObject instances the first argument to the constructor is 
self.conn, which is invalid.  I believe this should be changed to 
self.__conn.conn. 
 
A patch is attached (the patch has not been tested). 
 
Thanks! 

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

>Comment By: Billy G. Allie (ballie01)
Date: 2003-12-17 00:27

Message:
Logged In: YES 
user_id=8500

Fixed in version 1.40 of pyPgSQL/PgSQL.py

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

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

[Pypgsql-devel] [ pypgsql-Bugs-809127 ] DateTime parsing

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

Bugs item #809127, was opened at 2003-09-19 03:30
Message generated for change (Settings changed) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=809127&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Sergey Suleymanov (solt)
>Assigned to: Billy G. Allie (ballie01)
Summary: DateTime parsing

Initial Comment:
There is  a problem with parsing German datestyle by
the DateTime.ISO.ParseAny:

ValueError: unsupported format: "19.09.2003"

Maybe  DateTime.Parser.DateTimeFromString is better?


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

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

[Pypgsql-devel] [ pypgsql-Bugs-855987 ] TypeCache error (invalid constructor argument)

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

Bugs item #855987, was opened at 2003-12-08 11:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=855987&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Burton (bab)
Assigned to: Nobody/Anonymous (nobody)
Summary: TypeCache error (invalid constructor argument)

Initial Comment:
(Received through the Debian BTS as #221897.) 
 
Hi - there is a mistake in the TypeCache class, specifically in 
routines typecast() and handleArray().  When creating 
PgLargeObject instances the first argument to the constructor is 
self.conn, which is invalid.  I believe this should be changed to 
self.__conn.conn. 
 
A patch is attached (the patch has not been tested). 
 
Thanks! 

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

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

[Pypgsql-devel] [ pypgsql-Bugs-855986 ] Cannot connect to postgresql-7.4betaX databases

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

Bugs item #855986, was opened at 2003-12-08 11:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=855986&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Burton (bab)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot connect to postgresql-7.4betaX databases

Initial Comment:
(Received through the Debian BTS as #219862.) 
 
The PostgreSQL version string that is reported by 
postgresql-7.4beta5 (and all other betas) cannot be parsed by 
the pypgsql code. The problem is that the 'beta' in the version 
number confuses the parser in pgversion.c (in particular lines 
277 and on, in the function PgVersion_New) which creates a 
PgVersion object from the string that the server reports.  The 
function errors out and the connection fails.  
 
Thanks! 

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

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

[Pypgsql-devel] Note regarding bigint index performance...

[Mike C. F. <mcf...@ro...>]

Ivar Zarrans and myself have both encountered (separately) an 
interesting "bug" in PostgreSQL performance.  Basically, the query 
planner, if given a query like this:

    UPDATE trigger SET frozen=False WHERE object_id=23;

where object_id is an indexed big-int field of trigger, will *always* 
choose a sequential scan.  On a large table, that is going to be 
unacceptably slow, especially when one is writing the queries with the 
assumption that you are using an indexed field.  The problem here is 
that, even when a PgInt8 is passed as the object_id value, it is 
inserted into the query as an int4 literal (a simple number).  The 
server then sees a request to search for the field with a value of a 
*different type* than the available index, so ignores the index.

Apparently PostgreSQL 7.5 has a fix checked in for it, however, in the 
meantime, any 7.4 or below DB using bigints for specifying where's on 
large tables will be ridiculously slow on UPDATE (think multiple whole 
minutes to update a single row of a 88,000 row table).  Apparently this 
is a general problem, int2 indexed fields also won't use the index if an 
int4 literal is specified as the search term, though I'd guess that int8 
is the most common problem, as both people discovering it were using that.

This can be worked around by:

    * adding quotes around the value '23', which will make it an unknown
      type
    * coercing value to target type; i.e. 23::bigint anywhere you are
      using an integer as a query term against a field that is int8 and
      for which you need indexing
    * altering all queries to explicitly coerce to the target type
    * Greg Stark, on the postgres performance list, suggested using "the
      new binary protocol for parameters [within pyPgSQL] so that there
      are no quoting issues at all", but that's not going to work with
      older PostgreSQL versions, and still wouldn't help if someone had
      passed a regular integer (it would help if a PgInt8 was passed,
      however).

The first two need to be done by creating a subclass or wrapper of 
PgInt8 which does the munged representation in it's __str__/__repr__ 
method (so that pyPgSQL won't complain about an improperly formatted 
value).  Here's a sample class:

    class Wrapper:
        def __init__( self, value ):
            self.value = value
        def __repr__( self ):
            return '%s::int8'%(self.value, )
        __str__ = __repr__

It doesn't address the underlying problem, but it should allow people to 
move forward if they find themselves in this situation.

Enjoy,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [Pypgsql-devel] Error to report when connection to database is lost...

[Mike C. F. <mcf...@ro...>]

Gerhard Häring wrote:
...

> If we wanted to distinguish between these two, we'd need to parse the 
> PostgreSQL error strings, though.
>
> I'm personally against implementing this, because this whole error 
> message business looks like a mess to me in older PostgreSQL versions.
>
> PostgreSQL 7.4 and later, however, now have a reasonable error message 
> API, with error codes [1] that we could easily map to the 
> corresponding DB-API exception classes.
>
> -- Gerhard
>
> [1] 
> http://www.postgresql.org/docs/current/interactive/errcodes-appendix.html

Sorry for taking so long to reply on this...

I'm fine with leaving it as-is for 7.3, now that 7.4 is released.  I'm 
wondering, though, does this mean that we'll need to match pyPgSQL 
version to PostgreSQL version, or is detection of postgres back-end 
version available?  I'm working around the problem in my code (marking 
the connection invalid-and-to-be-recreated on *any* error), which is not 
optimal (there are, as a result, effectively no recoverable errors), but 
works ATM).

Enjoy,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[Pypgsql-devel] [ pypgsql-Patches-852606 ] Fix for Fedora linux with patched PostgreSQL pacakages

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

Patches item #852606, was opened at 2003-12-02 07:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=852606&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick Wagstrom (pridkett)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for Fedora linux with patched PostgreSQL pacakages

Initial Comment:
Fedora Linux Core 1 has a patched version of PostgreSQL
that reports it's version as 7.3.4-RH which causes the
version checking procedure to die and report that we're
not connecting to a valid database.  This fixes that
and makes it so versions that end in "-RH" are
recognized as valid versions, allowing pyPgSQL to work
under Fedora Core 1 (and I'd imagine anyplace else with
the RedHat database).

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

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

Re: [Pypgsql-devel] Error to report when connection to database is lost...

[<gh...@gh...>]

Mike C. Fletcher wrote:
> I'm working on making my dbapi wrapper capable of detecting a situation 
> where the database has gone down while a connection is held.  i.e. this 
> sequence...
> 
>    c = driver.connect()
>    <database goes down, (and comes back up again, though that's
>    irrelevant here)>
>    c.cursor.execute( x )
> 
> Now, what I would expect to be raised is:
> 
>    OperationalError [...]

I agree with you. However, all we get from the PostgreSQL side in an 
error case are PGRES_BAD_RESPONSE, PGRES_NONFATAL_ERROR or 
PGRES_FATAL_ERROR.

Currently, in case of PGRES_NONFATAL_ERROR we raise a ProgrammingError, 
while it could be either a ProgrammingError or an OperationalError.

If we wanted to distinguish between these two, we'd need to parse the 
PostgreSQL error strings, though.

I'm personally against implementing this, because this whole error 
message business looks like a mess to me in older PostgreSQL versions.

PostgreSQL 7.4 and later, however, now have a reasonable error message 
API, with error codes [1] that we could easily map to the corresponding 
DB-API exception classes.

-- Gerhard

[1] 
http://www.postgresql.org/docs/current/interactive/errcodes-appendix.html

[Pypgsql-devel] Error to report when connection to database is lost...

[Mike C. F. <mcf...@ro...>]

I'm working on making my dbapi wrapper capable of detecting a situation 
where the database has gone down while a connection is held.  i.e. this 
sequence...

    c = driver.connect()
    <database goes down, (and comes back up again, though that's
    irrelevant here)>
    c.cursor.execute( x )

Now, what I would expect to be raised is:

    OperationalError

        Exception raised for errors that are related to the database's
        operation and not necessarily under the control of the
        programmer, e.g. an unexpected disconnect occurs, the data
        source name is not found, a transaction could not be processed,
        a memory allocation error occurred during processing, etc. It
        must be a subclass of DatabaseError.

whereas what *is* raised is:

    ProgrammingError: (SQLQuery) could not receive data from server:
    Software caused connection abort (0x00002745/10053)

where ProgrammingError is supposed to be:

    ProgrammingError

        Exception raised for programming errors, e.g. table not found or
        already exists, syntax error in the SQL statement, wrong number
        of parameters specified, etc.  It must be a subclass of
        DatabaseError.

Seems that it really should be an operational error, as the server going 
down doesn't really constitute a programmer-avoidable situation.

Enjoy,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[Pypgsql-devel] [ pypgsql-Bugs-841530 ] PgNumeric.__rmul__

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

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

>Category: PgSQL
Group: None
>Status: Pending
>Resolution: Fixed
>Priority: 7
Submitted By: Laszlo Dobrontei (ubcsi)
>Assigned to: Billy G. Allie (ballie01)
Summary: PgNumeric.__rmul__

Initial Comment:
I have seen that you had fixed the problem with 
__radd__. The problem is same with __rmul__.


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

>Comment By: Billy G. Allie (ballie01)
Date: 2003-11-22 00:37

Message:
Logged In: YES 
user_id=8500

Updated pyPgSQL/PgSQL.py file was added to CVS repository.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-841530 ] PgNumeric.__rmul__

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

Bugs item #841530, was opened at 2003-11-13 17:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=841530&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Laszlo Dobrontei (ubcsi)
Assigned to: Nobody/Anonymous (nobody)
Summary: PgNumeric.__rmul__

Initial Comment:
I have seen that you had fixed the problem with 
__radd__. The problem is same with __rmul__.


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

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

[Pypgsql-devel] [ pypgsql-Bugs-838317 ] Memory corruption in bytea handling

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

Bugs item #838317, was opened at 2003-11-08 00:20
Message generated for change (Settings changed) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=838317&group_id=16528

Category: libpq
Group: None
>Status: Pending
Resolution: Fixed
Priority: 5
Submitted By: James Matthew Farrow (jmfarrow)
Assigned to: Billy G. Allie (ballie01)
Summary: Memory corruption in bytea handling

Initial Comment:
In unQuoteBytea the line (near the end)

    sout[j] = (char)0;

in both unecessary (since Py_BuildValue for s# takes a
length)
and wrong.  The memory allocated for sout is only the
same size as sin.  If no characters require unquoting
in sin then this NUL ends up being placed _outside_ the
allocated memory and will corrupt things.

The line should be removed.

 I suspect an extraneous NUL is also being appended in
libPQquoteBytea.

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

Comment By: Billy G. Allie (ballie01)
Date: 2003-11-09 22:02

Message:
Logged In: YES 
user_id=8500

Yes, the sout[j] = 0 in unQuoteBytea is an error.

There is a NUl being appended in libPQquoteBytea is
extraneous, but does not cause a problem as it is accounted
for in the size calculation of the buffer.  Still it is not
needed and has been removed.

The code has been updated in CVS.

Thanks for the bug report and fix James.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-838317 ] Memory corruption in bytea handling

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

Bugs item #838317, was opened at 2003-11-08 00:20
Message generated for change (Comment added) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=838317&group_id=16528

Category: libpq
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: James Matthew Farrow (jmfarrow)
>Assigned to: Billy G. Allie (ballie01)
Summary: Memory corruption in bytea handling

Initial Comment:
In unQuoteBytea the line (near the end)

    sout[j] = (char)0;

in both unecessary (since Py_BuildValue for s# takes a
length)
and wrong.  The memory allocated for sout is only the
same size as sin.  If no characters require unquoting
in sin then this NUL ends up being placed _outside_ the
allocated memory and will corrupt things.

The line should be removed.

 I suspect an extraneous NUL is also being appended in
libPQquoteBytea.

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

>Comment By: Billy G. Allie (ballie01)
Date: 2003-11-09 22:02

Message:
Logged In: YES 
user_id=8500

Yes, the sout[j] = 0 in unQuoteBytea is an error.

There is a NUl being appended in libPQquoteBytea is
extraneous, but does not cause a problem as it is accounted
for in the size calculation of the buffer.  Still it is not
needed and has been removed.

The code has been updated in CVS.

Thanks for the bug report and fix James.

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

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

[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 ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=829744&group_id=16528

Category: PgInt8
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Mike C. Fletcher (mcfletch)
>Assigned to: Billy G. Allie (ballie01)
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: Billy G. Allie (ballie01)
Date: 2003-11-09 21:57

Message:
Logged In: YES 
user_id=8500

I've applied your fix to the code in the CVS repository.

Thanks for the fix Mike.

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

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

[Pypgsql-devel] [ pypgsql-Patches-773489 ] Add support for 'infinity' in query-results

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

Patches item #773489, was opened at 2003-07-18 04:41
Message generated for change (Settings changed) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=773489&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Langås (tlan)
>Assigned to: Billy G. Allie (ballie01)
Summary: Add support for 'infinity' in query-results

Initial Comment:
Today (tested with your 2.4-release, as well), it crashes 
with an exception when DATETIME-fields 
contains 'infinity'.

On line 800 in PgSQL.py add:
                if value in ('infinity', '+infinity', '-infinity'):
                    fake_infinity = '9999-12-13 23:59:59'    # 
fake infinity      
                    if value[0] == '-':
                        value = '-' + fake_infinity
                    else:
                        value = fake_infinity


Maybe you want to add some sort of constant 
somewhere or something, so that one can do if 
date=<constant> to check for infinity, so that one can 
change the date/time at a later date,without breaking 
programs.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-838317 ] Memory corruption in bytea handling

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

Bugs item #838317, was opened at 2003-11-08 05:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=838317&group_id=16528

Category: libpq
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Matthew Farrow (jmfarrow)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory corruption in bytea handling

Initial Comment:
In unQuoteBytea the line (near the end)

    sout[j] = (char)0;

in both unecessary (since Py_BuildValue for s# takes a
length)
and wrong.  The memory allocated for sout is only the
same size as sin.  If no characters require unquoting
in sin then this NUL ends up being placed _outside_ the
allocated memory and will corrupt things.

The line should be removed.

 I suspect an extraneous NUL is also being appended in
libPQquoteBytea.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-829727 ] 0 or 1 not accepted for booleans...

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

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

Category: PgBoolean
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Mike C. Fletcher (mcfletch)
>Assigned to: Billy G. Allie (ballie01)
Summary: 0 or 1 not accepted for booleans...

Initial Comment:
Not sure whether this is really fixable in PyPgSQL, but
I spent quite some time fixing it in my apps. 
Basically, to declare a boolean for PostgreSQL you need
to have SQL syntax something like:

    True, '1','t','True'

and not:

    1

Given that the DB-API advocates, wherever possible,
using the driver's escaping mechanism, new users
(myself included) will often pass in common old-style
python boolean values (i.e. 1,0) (particularly in
Python 2.2.x) to queries as parameters for escaping.

To fix it, you'd need to know the context of the query
(i.e. that the value needs to be a boolean, not a
number), so I'm not at all confident that PyPgSQL can
do the escaping properly (or even if it would be
desirable to do so).  It can be worked around by
rewriting applications to use a back-ported Python 2.3
bool class (with __str__ giving True/False) whereever
booleans come in contact with SQL escaping.  (Or I
would assume by using PgBoolean in the same way).

If it's not fixable, a FAQ entry describing the
problem, and pointing to
http://www.python.org/peps/pep-0285.html (which has the
code to back-port true booleans to Python 2.2.x).

sqlquery.SQLQuery( sql="""INSERT INTO
	person( login, person_active, upass)
	VALUES ('jed',%(active)s, 'blah')""" 
)(
	connection,
	#active = booleanfix.bool(0),
	active = 0,
)

gives

V:\cinemon>boolean_problem.py
Traceback (most recent call last):
  File "V:\cinemon\boolean_problem.py", line 17, in ?
    active = 0,
  File "p:\table\pytable\sqlquery.py", line 87, in __call__
    self.do( cursor=cursor, query=query, **namedarguments)
  File "p:\table\pytable\sqlquery.py", line 109, in do
    raise err.__class__( """(SQLQuery) %s\nQuery:
%s\nArguments: %s"""%(
libpq.OperationalError: (SQLQuery) ERROR:  column
"person_active" is of type boolean but expression is of
type integer
        You will need to rewrite or cast the expression

Query: INSERT INTO
        person( login, person_active, upass)
        VALUES ('jed',0, 'blah')
Arguments: {'active': 0}

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

>Comment By: Billy G. Allie (ballie01)
Date: 2003-10-27 10:38

Message:
Logged In: YES 
user_id=8500

pyPgSQL supplies a type name PgBoolean to support booleans
in PostgreSQL.  In your example above, you would set
    active = PgSQL.PgBoolean(0 [or 1 or 'Y' or 'N' or 'Yes',
etc])
PgBooleans will be quoted properly.  For example:

>>> from pyPgSQL import PgSQL
>>> cx = PgSQL.connect()
>>> cx.conn.toggleShowQuery
'On'
>>> cu = cx.cursor()
QUERY: BEGIN WORK
>>> active = 1
>>> cu.execute('update atable set person_active = %s',
PgSQL.PgBoolean(active))
QUERY: update atable set person_active = 't'
>>> active = PgSQL.PG_False
>>> cu.execute('update atable set person_active = %s', active)
QUERY: BEGIN WORK
QUERY: update atable set person_active = 'f'
>>> cu.execute('update atable set person_active = %s',
PgSQL.PgBoolean('Yes'))
QUERY: BEGIN WORK
QUERY: update atable set person_active = 't'
>>>

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

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

[Pypgsql-devel] [ pypgsql-Bugs-829727 ] 0 or 1 not accepted for booleans...

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

Bugs item #829727, was opened at 2003-10-24 13:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=829727&group_id=16528

Category: PgBoolean
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Nobody/Anonymous (nobody)
Summary: 0 or 1 not accepted for booleans...

Initial Comment:
Not sure whether this is really fixable in PyPgSQL, but
I spent quite some time fixing it in my apps. 
Basically, to declare a boolean for PostgreSQL you need
to have SQL syntax something like:

    True, '1','t','True'

and not:

    1

Given that the DB-API advocates, wherever possible,
using the driver's escaping mechanism, new users
(myself included) will often pass in common old-style
python boolean values (i.e. 1,0) (particularly in
Python 2.2.x) to queries as parameters for escaping.

To fix it, you'd need to know the context of the query
(i.e. that the value needs to be a boolean, not a
number), so I'm not at all confident that PyPgSQL can
do the escaping properly (or even if it would be
desirable to do so).  It can be worked around by
rewriting applications to use a back-ported Python 2.3
bool class (with __str__ giving True/False) whereever
booleans come in contact with SQL escaping.  (Or I
would assume by using PgBoolean in the same way).

If it's not fixable, a FAQ entry describing the
problem, and pointing to
http://www.python.org/peps/pep-0285.html (which has the
code to back-port true booleans to Python 2.2.x).

sqlquery.SQLQuery( sql="""INSERT INTO
	person( login, person_active, upass)
	VALUES ('jed',%(active)s, 'blah')""" 
)(
	connection,
	#active = booleanfix.bool(0),
	active = 0,
)

gives

V:\cinemon>boolean_problem.py
Traceback (most recent call last):
  File "V:\cinemon\boolean_problem.py", line 17, in ?
    active = 0,
  File "p:\table\pytable\sqlquery.py", line 87, in __call__
    self.do( cursor=cursor, query=query, **namedarguments)
  File "p:\table\pytable\sqlquery.py", line 109, in do
    raise err.__class__( """(SQLQuery) %s\nQuery:
%s\nArguments: %s"""%(
libpq.OperationalError: (SQLQuery) ERROR:  column
"person_active" is of type boolean but expression is of
type integer
        You will need to rewrite or cast the expression

Query: INSERT INTO
        person( login, person_active, upass)
        VALUES ('jed',0, 'blah')
Arguments: {'active': 0}

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

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

[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 (Tracker Item Submitted) made by Item Submitter
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
...

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

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

[Pypgsql-devel] Int8 problem (bug # 829744), fix added to the bug-report

[Mike C. F. <mcf...@ro...>]

I've just finished working through a bug in the formatting code for 
pgint8object.c .  Short summary, MSVC6.0 doesn't recognise %lld as an 
(s|f)printf operator.  It requires %I64d instead.  I've posted the fixed 
functions to the bug-report here:

https://sourceforge.net/tracker/index.php?func=detail&aid=829744&group_id=16528&atid=116528

If someone would like to try testing it on another platform and checking 
it in I'd be most appreciative.

Enjoy,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[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

[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: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