pypgsql-devel — List for discussion of pyPgSQL development.

[Pypgsql-devel] [ pypgsql-Patches-1154791 ] Postgres include files in /usr/include/postgresql on Debian

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

Patches item #1154791, was opened at 2005-03-02 14:53
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=1154791&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew McNamara (andrewmcnamara)
Assigned to: Nobody/Anonymous (nobody)
Summary: Postgres include files in /usr/include/postgresql on Debian

Initial Comment:
Postgresql include files are in /usr/include/postgresql on Debian 
systems. This patch adds this directory to the setup.py include_dirs.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-1005037 ] Problem with pgInt8 not defined

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

Bugs item #1005037, was opened at 2004-08-07 09:26
Message generated for change (Settings changed) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1005037&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Millman (frankmillman)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with pgInt8 not defined

Initial Comment:
This is a copy of a message sent to comp.lang.python 
regarding a possible bug in pgPySQL. It is rather long, 
but I have reproduced it verbatim as any/all of it may be 
significant. Thanks.


Below is the text of a message I was about to send in 
connection with
an obscure problem. I have now almost got to the 
bottom of it, and am
fairly confident that it is a bug in pyPgSQL. I hope this is 
the
correct place to report such bugs. If not, please advise 
the correct
forum.

I have left the original message intact as it provides 
important
information. At the bottom, I have recorded the new 
information that I
have discovered.

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

Here is an obscure problem. I am not sure if I can 
explain the
symptoms properly, but I will do my best.

I have a Linux box (RH9) and an MSW box (W2K Pro) 
networked to each
other. Both are running Python 2.3.3.

Linux is the server. It is running PostgreSQL, which 
listens on port
5432. It is also running a socket server program that I 
have written
using socket.socket(), listening on port 6543. I am using 
pyPgSQL to
connect to the database.

MSW is the client. From time to time it sends messages 
to my socket
server. Messages are strings consisting of a single digit 
identifier,
followed by a cPickle'd tuple containing various data 
fields. The
client uses cPickle.dumps to prepare the string before 
sending, and
the server uses cPickle.loads to unpickle it after 
receiving.

Most times it works perfectly, but in one particular 
situation the
server terminates with an error. The error is consistent - 
it always
gives the same error resulting from the same message. 
However, I do
not think it is caused by the message itself, as exactly 
the same
message is sent in different circumstances without 
generating an
error.

The traceback is as follows -

    File "./chag_server.py", line 190, in ?
      dat = cPickle.loads(data[1:])
    File "/usr/local/lib/python2.3/site-
packages/pyPgSQL/libpq/__init__.py",
line 43, in _I8
      return PgInt8(value)
    NameError: ("global name 'PgInt8' is not defined", 
<function _I8
at 0x403a04c4>, ('17',))

The error occurs at the point of unpickling - I have 
moved this
around, and it always fails at this point.

A typical example of the tuple being unpickled is 
(2,'Ar',17,1) - it
is all normal strings and integers.

I have no idea why pyPgSQL is involved at all - I am 
certainly not
invoking it directly. In fact the error comes from my 
server program,
and that does not even import pyPgSQL.

Here are the relevant lines from 
pyPgSQL/libpq/__init__.py -

    from libpq import *
    from libpq import __version__

    HAVE_LONG_LONG_SUPPORT = dir().count('PgInt8') 
== 1

    #--------------------------------------------------
-------------+
    # Add support to pickle the following pyPgSQL 
objects:          |
    #       PgInt2, PgInt8, 
PgBoolean                               |
    #--------------------------------------------------
-------------+

    def _B(value):
        return PgBoolean(value)

    def _I2(value):
        return PgInt2(value)

    def _I8(value):
        return PgInt8(value)

Somehow pyPgSQL is responding to my unpickling 
command, and raising an
error because PgInt8 is not defined.

Here is another fact, which may provide a clue or may 
add confusion.
If I run exactly the same program from the Linux box, 
using it as the
client as well as the server, the error does not appear. I 
connect via
the external IP address, not via 127.0.0.1, so I would 
have thought it
would behave the same, but it does not.

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

Ok, here is the reason. I mentioned above that a typical 
tuple
consists of (2,'Ar',17,1). I have found that under some 
circumstances
the 3rd element is of type 'long' instead of type 'int', 
and this is
what generates the error.

Whether it is a long or an int is determined by pyPgSQL 
itself. It is
a column value, where the column is of type 'serial', 
which means that
PostgreSQL will generate a next number if the row is 
being inserted.
If the row exists, the column value is returned along 
with all the
other columns, and is returned as type int. If the row 
does not exist,
I insert it, and then to retrieve the id generated, I have 
the
following piece of code -

    cur = db.cursor()
    cur.execute("select currval('%s_%s_Seq')" % 
(tableid,columnid) )
    rowid = cur.fetchone()[0]

In this case, rowid contains the correct value, but is of 
type long.

So this raises various questions -

Why is PgInt8 not defined?
Why does pyPgSQL affect my server program, which 
does not import any
of pyPgSQL?
Why does the error only occur when I connect from a 
remote machine?

Now that I have identified the problem, I can work 
around it, so this
has become a matter of correctness rather than a 
matter of urgency.

Frank Millman


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

Comment By: Frank Millman (frankmillman)
Date: 2004-08-09 11:29

Message:
Logged In: YES 
user_id=1070042

Apologies - my diagnosis was not quite correct. What is 
actually happening is as follows.

Refer to the lines where I retrieve the id generated, ending 
with "rowid = cur.fetchone()[0]"

If this line is executed from a Linux machine, rowid's type 
is "long". If it is executed from a Windows machine, rowid's 
type is "PgInt8".

This explains why the error only occurs when I connect from 
the Windows machine.

Frank


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

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

[Pypgsql-devel] [ pypgsql-Bugs-1051520 ] __unicodeConvert doesn't support PgArray of Unicode Strings

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

Bugs item #1051520, was opened at 2004-10-21 16:23
Message generated for change (Settings changed) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1051520&group_id=16528

Category: PgSQL
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Florquin Renaud (florquin)
Assigned to: Nobody/Anonymous (nobody)
Summary: __unicodeConvert doesn't support PgArray of Unicode Strings

Initial Comment:

If we have PgArray of Unicode Strings, PyPgSQL fails. 

E.g. 

c = db.cursor()
query = "CREATE TABLE test (id TEXT, values TEXT[]);
c.execute(query)

query = "INSERT INTO test values (%s, %s);"
values = []
values.append(1)
values.append([u"abc", u"dé"])
c.execute(query, values)
c.close()
db.commit()

  File "D:\Soft\Python23\lib\site-
packages\pyPgSQL\PgSQL.py", line 3054, in execute
    parms = _quoteall(parms[0])
  File "D:\Soft\Python23\lib\site-
packages\pyPgSQL\PgSQL.py", line 2286, in _quoteall
    t = tuple(map(_quote, vdict))
  File "D:\Soft\Python23\lib\site-
packages\pyPgSQL\PgSQL.py", line 2255, in _quote
    return value._quote()
  File "D:\Soft\Python23\lib\site-
packages\pyPgSQL\PgSQL.py", line 1175, in _quote
    return _handleArray(self.value)
  File "D:\Soft\Python23\lib\site-
packages\pyPgSQL\PgSQL.py", line 2238, in _handleArray
    _j = '%s%s,' % (_j, PgQuoteString(str(_i), 1))
UnicodeEncodeError: 'ascii' codec can't encode 
character u'\x82' in position 0: ordinal not in range(128)


The cause is that the routine __unicodeConvert doesn't 
take into account PgArray of Unicode Strings

If we modify the __unicodeConvert and add the two 
marked line then there is no more error:

def __unicodeConvert(self, obj):
 if type(obj) is StringType:
  return obj
 elif type(obj) is UnicodeType:
  return obj.encode(*self.conn.client_encoding)
 elif type(obj) in (ListType, TupleType):
  converted_obj = []
  for item in obj:
   if type(item) is UnicodeType:
    converted_obj.append(item.encode
(*self.conn.client_encoding))
   elif isinstance(item, PgArray):    # !!!
    converted_obj.append(PgArray(self.__unicodeConvert
(item.value)))  # !!!
   else:
    converted_obj.append(item)
  return converted_obj


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

Comment By: Gerhard Häring (ghaering)
Date: 2005-02-27 19:41

Message:
Logged In: YES 
user_id=163326

Fixed in CVS.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-1055180 ] __unicodeConvert doesn't recognise subclasses of UnicodeType

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

Bugs item #1055180, was opened at 2004-10-27 12:02
Message generated for change (Settings changed) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1055180&group_id=16528

Category: PgSQL
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mike McGavin (jesterzog)
Assigned to: Nobody/Anonymous (nobody)
Summary: __unicodeConvert doesn't recognise subclasses of UnicodeType

Initial Comment:
Cursor.__unicodeConvert() (in PgSQL.py) doesn't encode
unicode strings all the time.

If the object that is passed is of a type that is a
subclass of a UnicodeType, rather than of the
UnicodeType itself, the __unicodeConvert() method
doesn't recognise it as unicode, even though it is.

This appears to be because most of the comparisons
within the __unicodeConvert() method use the "is"
operator to check the object type, which only compares
exact types and doesn't take sub-classing into account.

This bug may be able to be fixed quite easily, by
changing the comparisons (about 7 of them) to use
'isinstance()' instead of the 'is' operator.  ie. 
Instead of:

    if type(obj) is UnicodeType:
        doSomething()

the code should read:

    if isinstance(obj, UnicodeType):
        doSomething()


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

Comment By: Gerhard Häring (ghaering)
Date: 2005-02-27 19:40

Message:
Logged In: YES 
user_id=163326

Fixed in CVS.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-1016026 ] __unicodeConvert not recursive (class cursor)

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

Bugs item #1016026, was opened at 2004-08-25 16:45
Message generated for change (Settings changed) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1016026&group_id=16528

Category: PgResult
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Laurent Mignon (mignonlm)
Assigned to: Nobody/Anonymous (nobody)
Summary: __unicodeConvert not recursive (class cursor)

Initial Comment:
if a list item is a list of unicode value -> crash

def __unicodeConvert(self, obj):
	if type(obj) is StringType:
	    return obj
	elif type(obj) is UnicodeType:
	    return obj.encode
(*self.conn.client_encoding)
	elif type(obj) in (ListType, TupleType):
	    converted_obj = []
	    for item in obj:
		if type(item) is UnicodeType:
		    converted_obj.append(item.encode
(*self.conn.client_encoding))
		elif type(item) in (ListType, 
TupleType):    #add recursive routine
		    converted_obj.append
(self.__unicodeConvert(item))
		else:
		    converted_obj.append(item)
	    return converted_obj
	elif type(obj) is DictType:
	    converted_obj = {}
	    for k, v in obj.items():
		if type(v) is UnicodeType:
		    converted_obj[k] = v.encode
(*self.conn.client_encoding)
		else:
		    converted_obj[k] = v
	    return converted_obj
	elif isinstance(obj, PgResultSet):
	    obj = copy.copy(obj)
	    for k, v in obj.items():
		if type(v) is UnicodeType:
		    obj[k] = v.encode
(*self.conn.client_encoding)
	    return obj
	else:
	    return obj

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

Comment By: Gerhard Häring (ghaering)
Date: 2005-02-27 19:41

Message:
Logged In: YES 
user_id=163326

Fixed in CVS.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-1016010 ] __unicodeConvert not recursive (class cursor)

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

Bugs item #1016010, was opened at 2004-08-25 16:25
Message generated for change (Comment added) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1016010&group_id=16528

Category: PgResult
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Laurent Mignon (mignonlm)
Assigned to: Nobody/Anonymous (nobody)
Summary: __unicodeConvert not recursive (class cursor)

Initial Comment:
if a list item is a list of unicode value -> crash

def __unicodeConvert(self, obj):
	if type(obj) is StringType:
	    return obj
	elif type(obj) is UnicodeType:
	    return obj.encode
(*self.conn.client_encoding)
	elif type(obj) in (ListType, TupleType):
	    converted_obj = []
	    for item in obj:
		if type(item) is UnicodeType:
		    converted_obj.append(item.encode
(*self.conn.client_encoding))
		elif type(item) in (ListType, 
TupleType):    #add recursive routine
		    converted_obj.append
(self.__unicodeConvert(item))
		else:
		    converted_obj.append(item)
	    return converted_obj
	elif type(obj) is DictType:
	    converted_obj = {}
	    for k, v in obj.items():
		if type(v) is UnicodeType:
		    converted_obj[k] = v.encode
(*self.conn.client_encoding)
		else:
		    converted_obj[k] = v
	    return converted_obj
	elif isinstance(obj, PgResultSet):
	    obj = copy.copy(obj)
	    for k, v in obj.items():
		if type(v) is UnicodeType:
		    obj[k] = v.encode
(*self.conn.client_encoding)
	    return obj
	else:
	    return obj

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

>Comment By: Gerhard Häring (ghaering)
Date: 2005-02-27 19:41

Message:
Logged In: YES 
user_id=163326

Fixed in CVS.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-1016026 ] __unicodeConvert not recursive (class cursor)

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

Bugs item #1016026, was opened at 2004-08-25 16:45
Message generated for change (Comment added) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1016026&group_id=16528

Category: PgResult
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Laurent Mignon (mignonlm)
Assigned to: Nobody/Anonymous (nobody)
Summary: __unicodeConvert not recursive (class cursor)

Initial Comment:
if a list item is a list of unicode value -> crash

def __unicodeConvert(self, obj):
	if type(obj) is StringType:
	    return obj
	elif type(obj) is UnicodeType:
	    return obj.encode
(*self.conn.client_encoding)
	elif type(obj) in (ListType, TupleType):
	    converted_obj = []
	    for item in obj:
		if type(item) is UnicodeType:
		    converted_obj.append(item.encode
(*self.conn.client_encoding))
		elif type(item) in (ListType, 
TupleType):    #add recursive routine
		    converted_obj.append
(self.__unicodeConvert(item))
		else:
		    converted_obj.append(item)
	    return converted_obj
	elif type(obj) is DictType:
	    converted_obj = {}
	    for k, v in obj.items():
		if type(v) is UnicodeType:
		    converted_obj[k] = v.encode
(*self.conn.client_encoding)
		else:
		    converted_obj[k] = v
	    return converted_obj
	elif isinstance(obj, PgResultSet):
	    obj = copy.copy(obj)
	    for k, v in obj.items():
		if type(v) is UnicodeType:
		    obj[k] = v.encode
(*self.conn.client_encoding)
	    return obj
	else:
	    return obj

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

>Comment By: Gerhard Häring (ghaering)
Date: 2005-02-27 19:41

Message:
Logged In: YES 
user_id=163326

Fixed in CVS.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-1051520 ] __unicodeConvert doesn't support PgArray of Unicode Strings

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

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

Category: PgSQL
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Florquin Renaud (florquin)
Assigned to: Nobody/Anonymous (nobody)
Summary: __unicodeConvert doesn't support PgArray of Unicode Strings

Initial Comment:

If we have PgArray of Unicode Strings, PyPgSQL fails. 

E.g. 

c = db.cursor()
query = "CREATE TABLE test (id TEXT, values TEXT[]);
c.execute(query)

query = "INSERT INTO test values (%s, %s);"
values = []
values.append(1)
values.append([u"abc", u"dé"])
c.execute(query, values)
c.close()
db.commit()

  File "D:\Soft\Python23\lib\site-
packages\pyPgSQL\PgSQL.py", line 3054, in execute
    parms = _quoteall(parms[0])
  File "D:\Soft\Python23\lib\site-
packages\pyPgSQL\PgSQL.py", line 2286, in _quoteall
    t = tuple(map(_quote, vdict))
  File "D:\Soft\Python23\lib\site-
packages\pyPgSQL\PgSQL.py", line 2255, in _quote
    return value._quote()
  File "D:\Soft\Python23\lib\site-
packages\pyPgSQL\PgSQL.py", line 1175, in _quote
    return _handleArray(self.value)
  File "D:\Soft\Python23\lib\site-
packages\pyPgSQL\PgSQL.py", line 2238, in _handleArray
    _j = '%s%s,' % (_j, PgQuoteString(str(_i), 1))
UnicodeEncodeError: 'ascii' codec can't encode 
character u'\x82' in position 0: ordinal not in range(128)


The cause is that the routine __unicodeConvert doesn't 
take into account PgArray of Unicode Strings

If we modify the __unicodeConvert and add the two 
marked line then there is no more error:

def __unicodeConvert(self, obj):
 if type(obj) is StringType:
  return obj
 elif type(obj) is UnicodeType:
  return obj.encode(*self.conn.client_encoding)
 elif type(obj) in (ListType, TupleType):
  converted_obj = []
  for item in obj:
   if type(item) is UnicodeType:
    converted_obj.append(item.encode
(*self.conn.client_encoding))
   elif isinstance(item, PgArray):    # !!!
    converted_obj.append(PgArray(self.__unicodeConvert
(item.value)))  # !!!
   else:
    converted_obj.append(item)
  return converted_obj


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

>Comment By: Gerhard Häring (ghaering)
Date: 2005-02-27 19:41

Message:
Logged In: YES 
user_id=163326

Fixed in CVS.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-1055180 ] __unicodeConvert doesn't recognise subclasses of UnicodeType

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

Bugs item #1055180, was opened at 2004-10-27 12:02
Message generated for change (Comment added) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1055180&group_id=16528

Category: PgSQL
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Mike McGavin (jesterzog)
Assigned to: Nobody/Anonymous (nobody)
Summary: __unicodeConvert doesn't recognise subclasses of UnicodeType

Initial Comment:
Cursor.__unicodeConvert() (in PgSQL.py) doesn't encode
unicode strings all the time.

If the object that is passed is of a type that is a
subclass of a UnicodeType, rather than of the
UnicodeType itself, the __unicodeConvert() method
doesn't recognise it as unicode, even though it is.

This appears to be because most of the comparisons
within the __unicodeConvert() method use the "is"
operator to check the object type, which only compares
exact types and doesn't take sub-classing into account.

This bug may be able to be fixed quite easily, by
changing the comparisons (about 7 of them) to use
'isinstance()' instead of the 'is' operator.  ie. 
Instead of:

    if type(obj) is UnicodeType:
        doSomething()

the code should read:

    if isinstance(obj, UnicodeType):
        doSomething()


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

>Comment By: Gerhard Häring (ghaering)
Date: 2005-02-27 19:40

Message:
Logged In: YES 
user_id=163326

Fixed in CVS.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-1067857 ] Parameter mimatch in PgNumeric.__rmul__

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Peer (peergriebel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parameter mimatch in PgNumeric.__rmul__

Initial Comment:
Line 1598f has to read:

    def __rmul__(self, other):
	return self.__mul__(self, other)

instead of:

    def __rmul__(self, other):
	return self.__mul__(other)



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

>Comment By: Billy G. Allie (ballie01)
Date: 2005-02-23 00:58

Message:
Logged In: YES 
user_id=8500

The code is correct as is. 

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

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

[Pypgsql-devel] [ pypgsql-Bugs-1068856 ] PgNumeric(0,10,2)._quote() == 'NULL'

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

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

Category: PgNumeric
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Ken Lalonde (kenlalonde)
Assigned to: Nobody/Anonymous (nobody)
Summary: PgNumeric(0,10,2)._quote() == 'NULL'

Initial Comment:
A PgNumeric instance with value zero is incorrectly
quoted as 'NULL' instead of '0'.
Needless to say, this can have nasty consequences.

Fix is trivial: in version 2.4 of PgSQL.py:
--- PgSQL.py.old        2004-11-18 12:18:49.334613060 -0500
+++ PgSQL.py    2004-11-18 12:18:59.411482575 -0500
@@ -1664,7 +1664,7 @@
            return PgNumeric(-self.__v, self.__p, self.__s)
 
     def _quote(self, forArray=0):
-       if self.__v:
+       if self.__v is not None:
            if forArray:
                return '"%s"' % self.__fmtNumeric()
            else:


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

Comment By: Ken Lalonde (kenlalonde)
Date: 2004-11-18 14:11

Message:
Logged In: YES 
user_id=203927

Postscript: same bug affects PgMoney._quote; same fix.

While we're here, I see that PgNumeric._quote puts
single quotes around the return value.  This causes postgres
to convert a string to a NUMERIC(S,P) value.
Why not omit the quotes and keep it simple?

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

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

[Pypgsql-devel] [ pypgsql-Bugs-1056030 ] Numeric datatype loses digits

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

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

Category: libpq
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Peer (peergriebel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Numeric datatype loses digits

Initial Comment:
  select * from table
results in data rows. If the table includes numeric
columns digits are truncated: 4.56 will be returned as
4.6.  This does not happen using a statement like this:
  select * from table order by somecolumn


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

>Comment By: Billy G. Allie (ballie01)
Date: 2005-02-23 00:40

Message:
Logged In: YES 
user_id=8500

Changed code so that if the PgNumeric  prec/scale changes,
then it iwll use the new prec/sacle.  For example:

>>> cur.execute("""
... SELECT 123.4::numeric UNION
... SELECT 12345.4321::numeric UNION
... SELECT 0.00000987654321::numeric""")
>>> cur.fetchone()
[<PgNumeric instance - precision: 15 scale: 14 value:
0.00000987654321>]
>>> cur.fetchone()
[<PgNumeric instance - precision: 4 scale: 1 value: 123.4>]
>>> cur.fetchone()
[<PgNumeric instance - precision: 9 scale: 4 value: 12345.4321>]
>>>

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

Comment By: Peer (peergriebel)
Date: 2004-10-28 09:06

Message:
Logged In: YES 
user_id=1133977

After some investigation I discovered some more facts. You need:

0. (Use PgSQL 1.35)
1. A table with at least one numeric column (no precision,
no scale)
2. Insert data with different precision. E.g 3.1 and 4.56.
3. SELECT all rows from db with different ordering so that
first value (3.1) will be returned first/with second value
(4.56) returned first.

Then PgSQL tries to determine the precision of the numeric
column. Since the databse does not tell it tries to guess
(line #2859). It will guess by first value. So if 3.1 comes
first it guesses precision is 1. BUT THIS IS WRONG. If the
first fetched value is 4.56 it will guess precision is 2. 
Since the TypeCache uses it's knowlegde for all rows the
guessing is sometimes wrong.


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

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

[Pypgsql-devel] [ pypgsql-Bugs-1006782 ] pyPGSQL does not connect to PostgreSQL 8.0 Beta

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

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

Category: libpq
Group: None
Status: Pending
Resolution: Fixed
Priority: 5
Submitted By: Harald Armin Massa (ghum)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyPGSQL does not connect to PostgreSQL 8.0 Beta

Initial Comment:
While trying to connect to Postgresql 8.0, PyPGSQL raises

Invalid format for PgVersion construction.


Error. That's seems to be within 

PyObject *PgVersion_New(char *version)

of pgversion.c


What is going wrong?

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

Comment By: John F Meinel Jr (jfmeinel)
Date: 2005-02-20 23:12

Message:
Logged In: YES 
user_id=266114

Well, actually this was only a problem when postgres was
beta. For a full release, we would be okay, since the
version string changes to something that you are okay with.

However, it still fails with some other installations. For
instance, Red Hat Enterprise Linux 3 (RHEL3) installs the
Redhat Database (it may be modified), but the version string
is something like 7.4-RH, which also isn't beta, alpha,
devel, etc.

Is there a reason you have to be so strict about the
version? Can't you just accept anything that can be parsed
as Number.Number? Is there something else that uses the
version (like do you change how queries are structured?)

Thanks for looking into it, though. And it would be nice to
get a fresh release with some of the fixes. (Though I think
when I tried CVS head, I ran into problems because of some
of the other changes that were made.)


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

Comment By: Gerhard Häring (ghaering)
Date: 2004-10-05 03:11

Message:
Logged In: YES 
user_id=163326

Looks like it's time to get a few bugs fixed and make a
release that will work with Pg8.

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

Comment By: John F Meinel Jr (jfmeinel)
Date: 2004-09-08 11:26

Message:
Logged In: YES 
user_id=266114

I am unable to build from source. I have Visual Studio 7.1,
and not 6 to compile the library.

Can you run "py setup.py bdist_wininst" for me and either
post the installer, or send it to me?

Thanks,
John
=:->

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

Comment By: Harald Armin Massa (ghum)
Date: 2004-08-25 06:20

Message:
Logged In: YES 
user_id=665785

correcting myself...

if (pgstricmp(last, "beta") == 0)
    return (errno != 0);

pgstricmp does not take any length parameter 



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

Comment By: Harald Armin Massa (ghum)
Date: 2004-08-25 06:20

Message:
Logged In: YES 
user_id=665785

correcting myself...

if (pgstricmp(last, "beta") == 0)
    return (errno != 0);

pgstricmp does not take any length parameter 



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

Comment By: Harald Armin Massa (ghum)
Date: 2004-08-25 06:19

Message:
Logged In: YES 
user_id=665785

Thank you very much, mfuhr... 

I looked at the "devel" check and propose to do 

if (pgstricmp(last, "beta", 4) == 0)
    return (errno != 0);
    
instead of strncmp ... I suppose the PostgreSQL developers
had their reason to provide their own strcmp, or?



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

Comment By: Michael Fuhr (mfuhr)
Date: 2004-08-23 22:47

Message:
Logged In: YES 
user_id=655499

PgVersion_New() calls parseToken(), which doesn't allow for
the string "beta" in the last token of "8.0.0beta1". 
parseToken() checks for "devel" and a few other cases, but
not for "beta".  I got it to work by adding the following
lines after the check for "devel":

if (strncmp(last, "beta", 4) == 0)
    return (errno != 0);


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

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

[Pypgsql-devel] [ pypgsql-Bugs-1006782 ] pyPGSQL does not connect to PostgreSQL 8.0 Beta

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

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

Category: libpq
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Harald Armin Massa (ghum)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyPGSQL does not connect to PostgreSQL 8.0 Beta

Initial Comment:
While trying to connect to Postgresql 8.0, PyPGSQL raises

Invalid format for PgVersion construction.


Error. That's seems to be within 

PyObject *PgVersion_New(char *version)

of pgversion.c


What is going wrong?

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

Comment By: Gerhard Häring (ghaering)
Date: 2004-10-05 04:11

Message:
Logged In: YES 
user_id=163326

Looks like it's time to get a few bugs fixed and make a
release that will work with Pg8.

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

Comment By: John F Meinel Jr (jfmeinel)
Date: 2004-09-08 12:26

Message:
Logged In: YES 
user_id=266114

I am unable to build from source. I have Visual Studio 7.1,
and not 6 to compile the library.

Can you run "py setup.py bdist_wininst" for me and either
post the installer, or send it to me?

Thanks,
John
=:->

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

Comment By: Harald Armin Massa (ghum)
Date: 2004-08-25 07:20

Message:
Logged In: YES 
user_id=665785

correcting myself...

if (pgstricmp(last, "beta") == 0)
    return (errno != 0);

pgstricmp does not take any length parameter 



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

Comment By: Harald Armin Massa (ghum)
Date: 2004-08-25 07:20

Message:
Logged In: YES 
user_id=665785

correcting myself...

if (pgstricmp(last, "beta") == 0)
    return (errno != 0);

pgstricmp does not take any length parameter 



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

Comment By: Harald Armin Massa (ghum)
Date: 2004-08-25 07:19

Message:
Logged In: YES 
user_id=665785

Thank you very much, mfuhr... 

I looked at the "devel" check and propose to do 

if (pgstricmp(last, "beta", 4) == 0)
    return (errno != 0);
    
instead of strncmp ... I suppose the PostgreSQL developers
had their reason to provide their own strcmp, or?



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

Comment By: Michael Fuhr (mfuhr)
Date: 2004-08-23 23:47

Message:
Logged In: YES 
user_id=655499

PgVersion_New() calls parseToken(), which doesn't allow for
the string "beta" in the last token of "8.0.0beta1". 
parseToken() checks for "devel" and a few other cases, but
not for "beta".  I got it to work by adding the following
lines after the check for "devel":

if (strncmp(last, "beta", 4) == 0)
    return (errno != 0);


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&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-07 19:26
Message generated for change (Comment added) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=855986&group_id=16528

Category: None
Group: None
>Status: Pending
>Resolution: Fixed
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! 

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

>Comment By: Billy G. Allie (ballie01)
Date: 2005-02-20 22:22

Message:
Logged In: YES 
user_id=8500

Increased the robustness of pgversion to handle
devel/alpha/beta versions of PostgreSQL

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

Comment By: Gerhard Häring (ghaering)
Date: 2004-10-05 04:08

Message:
Logged In: YES 
user_id=163326

Can we drop the pgversion stuff? Alternatively, we must make
it more robust.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-1002323 ] Wrong scale/prec tests in PgNumeric

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

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

Category: PgSQL
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Hallvard B Furuseth (hfuru)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong scale/prec tests in PgNumeric

Initial Comment:
PgSQL.py 1.43:

PgNumeric.__init__(self, PgNumeric instance, ...)
has a test
   if scale:
which means a specified scale of 0 will be
ignored.  I think that should be
   if scale is not None:

The same applies to the 'if prec:' test
further down, but that's less serious since
prec may not be 0.


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

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

[Pypgsql-devel] [ pypgsql-Bugs-967372 ] PgNumeric.__cmp__ does not handle non-numbers

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

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

Category: PgNumeric
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Ben Burton (bab)
Assigned to: Nobody/Anonymous (nobody)
Summary: PgNumeric.__cmp__ does not handle non-numbers

Initial Comment:
Hi.  I received the following report through the debian BTS 
(#251401).  The fix is very simple (I've already applied it to the 
debian packages) -- simply change "return None" to "return 1" in 
the __cmp__ implementation.  The original bug report is below, 
and the one-line patch is attached. 
 
Ben. 
 
ORIGINAL BUG REPORT: 
 
I just had a website break due to what eventually turned out to 
be a bug in the __cmp__ method for PgNumeric.  The problem is 
a small bug in its return values: when it can not coerce the 
object it is compared to to a PgNumeric it returns None, which is 
not allowed for a __cmp__ function.  Simply fixing the return 
value fixes this, see the patch below. 
 

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

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

[Pypgsql-devel] [ pypgsql-Bugs-896600 ] Simple calling error

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

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

Category: PgSQL
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 6
Submitted By: Dick Kniep (dickkniep)
Assigned to: Billy G. Allie (ballie01)
Summary: Simple calling error

Initial Comment:
Enclosed an error listing which looks very easy to fix

  File "/home/dick/Clienten/src/Hoofdframe.py", line
297, in    
self.FactuurProductlist.BldList(clear=Opendb.TableObjs.RebuildFactList)
  File "/home/dick/Clienten/src/DefColumns.py", line
479, in BldList
    self.ShowScrn = self.VulScherm()
  File "/home/dick/Clienten/src/DefColumns.py", line
528, in VulScherm
    self.Vulrij(rec, self.n)
  File "/home/dick/Clienten/src/DefColumns.py", line
576, in Vulrij
    self.VulSchermKolommen(rec, teller)
  File "/home/dick/Clienten/src/DefColumns.py", line
658, in VulSchermKolommen
    strfld = self.GetField(kolom, fetchroutine, h, rec)
  File "/home/dick/Clienten/src/DefColumns.py", line
676, in GetField
    strfld = fetchroutine(rec, kolom)
  File "/home/dick/Clienten/src/Hoofdframe.py", line
65, in <lambda>
    ("regelprijs", lambda rec, veld:
self.getRegelPrijs(rec),"Regelprijs"))
  File "/home/dick/Clienten/src/Hoofdframe.py", line
127, in getRegelPrijs
    return str(rec.contractprijs * rec.aantal)
  File
"/usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py",
line 1598, in __rmul__
    return self.__mul__(self, other)
TypeError: __mul__() takes exactly 2 arguments (3 given)

Obviously this should be:
return self.__mul__(other)




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

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

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

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

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

Category: PgSQL
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 7
Submitted By: Ben Burton (bab)
Assigned to: Billy G. Allie (ballie01)
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. 

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

Comment By: Billy G. Allie (ballie01)
Date: 2004-01-18 21:31

Message:
Logged In: YES 
user_id=8500

The work around for the problem is to turn off the use of
PostgreSQL portals.

I will modify the code so that portals are not used both
select and into are used in the same query.

Yes, i know that there can be false positives (ie into is
used in a string in the query), but at worse, a portal will
not be used in this instance.  For the application point of
view, there is no difference.

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

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-21 08:39
Message generated for change (Settings changed) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=863925&group_id=16528

Category: PgSQL
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 7
Submitted By: Ben Burton (bab)
Assigned to: Billy G. Allie (ballie01)
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. :) 

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

Comment By: Billy G. Allie (ballie01)
Date: 2004-01-18 21:37

Message:
Logged In: YES 
user_id=8500

Thanks for the report and patch.  I will apply this to the code.

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

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

[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 08:40
Message generated for change (Settings changed) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=852606&group_id=16528

Category: None
Group: None
Status: Pending
Resolution: Fixed
Priority: 5
Submitted By: Patrick Wagstrom (pridkett)
Assigned to: Billy G. Allie (ballie01)
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).

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

Comment By: Billy G. Allie (ballie01)
Date: 2005-02-20 00:07

Message:
Logged In: YES 
user_id=8500

Applied patch suggested by shauncutts.

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

Comment By: Shaun Cutts (shauncutts)
Date: 2004-03-11 02:59

Message:
Logged In: YES 
user_id=232124

The following is an alternative solution. Either is needed
for RedHat ES as well as Fedora.

The submitted version seems to trim out "-RH" wherever it
occurs. This variation is to allow -<anything> after the
patch # in the version string.

A "real" fix for this would be to have newer postgres
support version_major() etc functions rather than having to
parse strings whose definitions aren't guarenteed.

diff pgversion.c-v1.21 pgversion.c
293c293
<       token = pg_strtok_r((char *)NULL, ".", &save_ptr);
---
>       token = pg_strtok_r((char *)NULL, ".-", &save_ptr);


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

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

[Pypgsql-devel] [ pypgsql-Patches-996442 ] PgSQL.Cursor.__fetchManyRows shoud use xrange

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

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

Category: None
Group: None
Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Michael Howitz (icemac)
Assigned to: Nobody/Anonymous (nobody)
Summary: PgSQL.Cursor.__fetchManyRows shoud use xrange

Initial Comment:
In PgSQL.Cursor.__fetchManyRows range(count) may
generate a huge list, if a large count is used. (This
happens in combination with ZpyPgSQLDA.db.DB.query with
no max_rows set (Its default is 9999999!))

Maybe using xrange can help, it speeds things
daratically up.
(see also
http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-73
)
So I attached a patch to use xrange instead of range.

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

Comment By: Billy G. Allie (ballie01)
Date: 2005-02-19 23:53

Message:
Logged In: YES 
user_id=8500

Applied patch

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

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

[Pypgsql-devel] [ pypgsql-Patches-1002802 ] libpqmodule spelling fix

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

Patches item #1002802, was opened at 2004-08-03 14:31
Message generated for change (Settings changed) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1002802&group_id=16528

Category: None
Group: None
Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Marc Recht (marc)
Assigned to: Nobody/Anonymous (nobody)
Summary: libpqmodule spelling fix 

Initial Comment:
The attached patch contains some trivial spelling fixes ( s/requireed/
required/g ) which we have in pkgsrc for a long time now. They are 
originally from FreeBSD ports, IIRC.

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

Comment By: Billy G. Allie (ballie01)
Date: 2005-02-19 23:50

Message:
Logged In: YES 
user_id=8500

Applied patch

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

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

[Pypgsql-devel] [ pypgsql-Patches-1029580 ] serious bug: unQuoteBytea allocates buffer that is too small

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

Patches item #1029580, was opened at 2004-09-16 20:09
Message generated for change (Settings changed) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1029580&group_id=16528

Category: None
Group: None
Status: Pending
>Resolution: Fixed
Priority: 8
Submitted By: Jey Kottalam (jeyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: serious bug: unQuoteBytea allocates buffer that is too small

Initial Comment:
In the case where unQuoteBytea is called with a string
that has no escaped characters, and unQuoteBytea
behaves like strcpy() to simply copy all the bytes in
the original string unmodified to the destination
string, the buffer is too small by one char. The buffer
allocated has the size strlen(sin) when it should have
the size strlen(sin)+1 to account for the terminating
NUL byte in C strings.

I have attached a patch to correct this problem. It
caused me a lot of pain with strange, semi-random
seeming bugs in my program. :-)

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

Comment By: Billy G. Allie (ballie01)
Date: 2005-02-19 23:48

Message:
Logged In: YES 
user_id=8500

Applied fix.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1029580&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 (Comment added) 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: Pending
>Resolution: Fixed
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.

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

>Comment By: Billy G. Allie (ballie01)
Date: 2005-02-20 00:11

Message:
Logged In: YES 
user_id=8500

Applied patch.

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

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