pypgsql-devel — List for discussion of pyPgSQL development.

[Pypgsql-devel] [ pypgsql-Feature Requests-708393 ] Moving to python2.2 new style classes and datetime

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

Feature Requests item #708393, was opened at 2003-03-23 10:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=366528&aid=708393&group_id=16528

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Christian Heimes (tiran)
Assigned to: Billy G. Allie (ballie01)
Summary: Moving to python2.2 new style classes and datetime

Initial Comment:
datetime:
http://www.python.org/dev/doc/devel/lib/module-datetime.html
new style classes:
http://www.python.org/doc/2.2.1/whatsnew/whatsnew22.html

Datetime will be a part of python2.3 and is used in zope3.

new style classes would ease up a lot of code, for example:

class PgInt8(long):
    pass

Christian

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

>Comment By: Billy G. Allie (ballie01)
Date: 2003-03-26 03:13

Message:
Logged In: YES 
user_id=8500

As Gerhard stated, the reason for the PgInt* types is that
the valid range for the various PostgreSQL integer types are
fixed and less then what can be represented by the python
types.  It a question of where you want to catch the error
-- in the front end or at the back end.  I prefer to catch
overflow errors in the front end.  Also, a constraint
failure specified on a field in a table (e.g. x must be
between y and z) is, to me, a different class of error than
trying to insert a value that is outside the range of the
given type.

That said, I agree that the current PgInt* types may be more
trouble than they are worth, since simple subclassing of the
type and adding a range check doesn't work in python 2.2.  I
think that the code could be change to return a Python int
(or long for PgInt8).  The PgInt* classes can remain and
could be used to cast the ints before sending them to the
backend if someone wanted to range check the values before
they are sent to the PostgreSQL backend.

Your thoughts?

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-23 16:05

Message:
Logged In: YES 
user_id=560817

For datetime: For now there is only a python prototype of
the new upcoming Datetime module shipped with Zope3. I hope
Datetime will be backported to Python-2.2.

For numeric: Perhaps you should have a glance on pynum
(numerical python) utilities. Users who needs exact
numerical representation of numbers would have pynum
installed, so you can use the pynum classes. If it's not
installed then it seams so that the users don't need excat
values.

For int and float: For me I have to convert all special
pyPgSQL types into ordenary types like int, float and long
to use them in Zope3. This is due the security framework of
Zope3. Every class, schema or type must have an interface
which describes, what methods and attributes are public
(very easy speaking, see Zope3 WikiWikiWeb for more
informations). In my opinion this is a performance leak.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 15:11

Message:
Logged In: YES 
user_id=163326

For datetime: if there's an easily installable (read:
distutilified) Python package for Python 2.2, we might use
the Python datetime stuff in pyPgSQL 3.x instead of mxDateTime.

Yes, Python's int, long, float can handle all numbers that
PostgreSQL can handle in the corresponding types. But not
necessarily the other way round. For example, a PgInt2 has a
much smaller range than a Python int. Ditto for PgInt8 and
Python long.

So if you insert a (large) long in a INT8 column, you can
get an ERROR from the PostgreSQL side. That was why Billy
implemented the PgInt* types, so he told me.

I personally (currently) don't think they're worth the
effort, as they only catch a (possibly small) range of
errors. For example, there could still be additional
CONSTRAINTs.

We still need an equivalent of NUMERIC, though. And this one
is the only really hard type to implement.


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

Comment By: Christian Heimes (tiran)
Date: 2003-03-23 14:40

Message:
Logged In: YES 
user_id=560817

The new Datetime module for python2.3 is used under both
python2.2 and python2.3 in the upcoming Zope3. It's tested
and often used. By the way it would help me implementing a
database adapter in Zope3. :)

Do we really need range checks for numerical types? I thougt
python's int, long and float could handle all numbers that
could be handled by postgres (maybe except of numeric).

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 13:30

Message:
Logged In: YES 
user_id=163326

First, exploiting new-style classes and other Pyhton 2.3
features are  what pyPgSQL 3.0 is all about.

It will require Python 2.2, but I don't think we'll want to
use the new datetime module from 2.3.

Unfortunately, the pyPgSQL developers are generally short on
time, that's why not that much has been accomplished on the
3.0 front, yet. At least from me ;-)

If you're interested in other plans, you can look in the
TODO file, which is in CVS.

Also note that the current PgInt* classes do range checks.
Just subclassing from long doesn't get us this feature.

I'm still sceptical about the merit of the PgInt* types, but
that's just my personal opinion and better discussed on the
mailing list.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-708002 ] interval (DateTimeDelta) returns maximal days

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

Bugs item #708002, was opened at 2003-03-22 08:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=708002&group_id=16528

Category: PgSQL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Heimes (tiran)
Assigned to: Billy G. Allie (ballie01)
Summary: interval (DateTimeDelta) returns maximal days

Initial Comment:
I'm working on a pyPgSQLDA for Zope3 (see
http://cvs.zope.org/zopeproducts/pypgsqlda/). I have
noticed a problem mit time intervals.

INSERT INTO testinterval VALUES('20 years');
INSERT INTO testinterval VALUES('20 days');

pyPgSQL returns 20.0 days for both statements, what is
really strange becauce the interval type is 12bytes
long and supports more than a billion years.



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

>Comment By: Billy G. Allie (ballie01)
Date: 2003-03-26 02:56

Message:
Logged In: YES 
user_id=8500

I belive the original problem of 20 days and 20 years
returning the same value is fixed in the latest PgSQL.py
from CVS:

bga=# \d dtest
     Table "public.dtest"
    Column |   Type   | Modifiers 
--------+----------+-----------
 a              | interval | 

bga=# select * from dtest;
        a        
-----------------
 20 years
 20 days
 7304 days 20:24
(3 rows)

bga=# \q
$ python
Python 2.2.2 (#7, Nov 27 2002, 17:10:05) [C] on openunix8
Type "help", "copyright", "credits" or "license" for more
information.
>>> from pyPgSQL import PgSQL
>>> cx = PgSQL.connect(password='**********')
>>> cu = cx.cursor()
>>> cu.execute('select * from dtest')
>>> r = cu.fetchall()
>>> for i in r:
...     print i
... 
[<DateTimeDelta object for '7304:20:24:00.00' at 81fc470>]
[<DateTimeDelta object for '20:00:00:00.00' at 81fa8b0>]
[<DateTimeDelta object for '7304:20:24:00.00' at 81fc5b0>]
>>> 

But PostgreSQL intervals seem wierd to me.  For examples:

An interval of 1 year is equal to an interval of 360 (not
365) days
bga=# select '1 year'::interval = '360 days'::interval;
 ?column? 
----------
 t
(1 row)

but adding an interval of 1 year to a date does the right thing:
bga=# select '7/11/1954'::date + '1 year'::interval;
      ?column?       
---------------------
 1955-07-11 00:00:00
(1 row)

Yet subtracting the dates give a value of 365:
bga=# select '7/11/1955'::date - '7/11/1954'::date;
 ?column? 
----------
      365
(1 row)


This is all very strange to me.  Futher investigation give:

1 year = 360 days
1 month = 30 days
1 month = 4 weeks 2 days
1 week = 7 days

which doesn't seem to bear much relationship to the actual 
number of days between 2 dates.  It seems to me that the
only way to accurately represent a PostgreSQL interval is to
do what PostgreSQL does and remember the original user
input, i.e. have an object with attributes for years,
months, weeks, days, hours, minutes, seconds.   Adding and
subtracting the interval from a date would then involve
adding/subtracting the parts to/from the date.

your thoughts?

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-23 16:12

Message:
Logged In: YES 
user_id=560817

I'll see what I can do. But at first I have to learn for
university

Maybe you are interested in my ideas of mapping some other
postgres specifiy types to python. I had first successes of
converting inet, cidr and the geometric types to lists and
tuples (see cvs.zope.org/zopeproducts/pypgsqlda).
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/68205
would be nice for the NULL value, too. The Null class
supports postgres like behavior like NULL != False, NULL !=
'', NULL != 0 ...

Christian

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 15:55

Message:
Logged In: YES 
user_id=163326

This sounds like the best option.

If you could provide a patch, that'd be great :-)

This also sounds like another change that'd justify a bugfix
release.

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-23 15:50

Message:
Logged In: YES 
user_id=560817

I think the best way to get rid of this silly problems with
date and time would be changing the orbit of earth and using
the Napoleon Calender.  Who wants to write a proposal how to
do this?
</joke>

Why not supporting both ways so the user can chocie wether
he wants to convert years to 365.24 days or get an exception?

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 15:39

Message:
Logged In: YES 
user_id=163326

Alternatively, we could look wether only days/hours/... are
used in the string, then use the mxDateTime function to
parse it. Otherwise, raise an exception.

At least this wouldn't fail silently, returning a wrong value.

Thoughts?

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-23 14:26

Message:
Logged In: YES 
user_id=560817

I studied my Practical Postgres book from o'reily and found
an instresting information. A 'postgres year' are 365.24 days.

My opinion is:
* convert a year to 365.24 days
* convert a moth to 365.24/12 days

This is not an excat translation from year to days, but
better then converting the string "20 years" to 20 days. I
think it's the best workaround to keep backward
compatibility to existing data.

* put a HUGHE warning in the readme of pypgsql

So programmers are informed about the problems that could
accure using years and month statements in INTERVAL.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 13:57

Message:
Logged In: YES 
user_id=163326

Assigning to Billy, because I just don't get it:

This is WEIRD. It seems PostgreSQL remembers the years and
months. I always thought it might convert everything into
some base, say seconds internally.

Looks like it doesn't.

This might sound like a provocation, but here it goes: if
PostgreSQL isn't smart enough to convert, say a year to 365
days, I don't think we should try to be so smart.

A DateTimeDelta from mxDateTime is an exact timespan, not a
remember-the-user-input thingie like PostgreSQL's INTERVAL
seems to be.

So it's not possible to do an exact conversion from INTERVAL
to DateTimeDelta in all cases. Where it is possible, I think
it currently works.

My solution for the application programmer is to only use
days/hours/seconds when inserting values into an INTERVAL
column.

I'd be glad to hear your opinion on this.

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-22 10:53

Message:
Logged In: YES 
user_id=560817

I did some more testing:

$ python2.2
Python 2.2.2 (#1, Jan 18 2003, 10:18:59)
[GCC 3.2.2 20030109 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from mx import DateTime
>>> t = DateTime.DateTimeDelta(7300)
>>> t
<DateTimeDelta object for '7300:00:00:00.00' at 819a1c0>
>>> t.days
7300.0
>>>

test=> SELECT * FROM testint;
  inter
----------
 20 days
 20 years
 2 mons
 20 years
 14 days
(5 rows)
These are the values from the database for: 20 days, 20
years, 2 month, 2 decades, 2 weeks

test=> SET DATESTYLE TO NONEUROPEAN, GERMAN;
SET VARIABLE
test=> SELECT * FROM testint;
   inter
------------
 @ 20 days
 @ 20 years
 @ 2 mons
 @ 20 years
 @ 14 days
(5 rows)

mons and years are not supported by
PgSQL.TypeCache.interval2datetimedelta

Maybe you could convert them to the following values:
1 Month -> 30 days
3 Month -> 91 days (?)
6 Month -> 182 days (?)
12 Month -> 1 year
20 Month -> 1 year and 8 month
1 year -> 365 days
4 years -> 1461 days (4* 1 years + 1 day) (?)
400 years -> 146099 days (100 * 4 years - 1 day) (?)
2000 years -> 730496 (5* 400 years +1 day) (?)

Christian

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

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

[Pypgsql-devel] [ pypgsql-Bugs-708002 ] interval (DateTimeDelta) returns maximal days

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

Bugs item #708002, was opened at 2003-03-22 14:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=708002&group_id=16528

Category: PgSQL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Heimes (tiran)
Assigned to: Billy G. Allie (ballie01)
Summary: interval (DateTimeDelta) returns maximal days

Initial Comment:
I'm working on a pyPgSQLDA for Zope3 (see
http://cvs.zope.org/zopeproducts/pypgsqlda/). I have
noticed a problem mit time intervals.

INSERT INTO testinterval VALUES('20 years');
INSERT INTO testinterval VALUES('20 days');

pyPgSQL returns 20.0 days for both statements, what is
really strange becauce the interval type is 12bytes
long and supports more than a billion years.



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

>Comment By: Christian Heimes (tiran)
Date: 2003-03-23 22:12

Message:
Logged In: YES 
user_id=560817

I'll see what I can do. But at first I have to learn for
university

Maybe you are interested in my ideas of mapping some other
postgres specifiy types to python. I had first successes of
converting inet, cidr and the geometric types to lists and
tuples (see cvs.zope.org/zopeproducts/pypgsqlda).
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/68205
would be nice for the NULL value, too. The Null class
supports postgres like behavior like NULL != False, NULL !=
'', NULL != 0 ...

Christian

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 21:55

Message:
Logged In: YES 
user_id=163326

This sounds like the best option.

If you could provide a patch, that'd be great :-)

This also sounds like another change that'd justify a bugfix
release.

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-23 21:50

Message:
Logged In: YES 
user_id=560817

I think the best way to get rid of this silly problems with
date and time would be changing the orbit of earth and using
the Napoleon Calender.  Who wants to write a proposal how to
do this?
</joke>

Why not supporting both ways so the user can chocie wether
he wants to convert years to 365.24 days or get an exception?

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 21:39

Message:
Logged In: YES 
user_id=163326

Alternatively, we could look wether only days/hours/... are
used in the string, then use the mxDateTime function to
parse it. Otherwise, raise an exception.

At least this wouldn't fail silently, returning a wrong value.

Thoughts?

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-23 20:26

Message:
Logged In: YES 
user_id=560817

I studied my Practical Postgres book from o'reily and found
an instresting information. A 'postgres year' are 365.24 days.

My opinion is:
* convert a year to 365.24 days
* convert a moth to 365.24/12 days

This is not an excat translation from year to days, but
better then converting the string "20 years" to 20 days. I
think it's the best workaround to keep backward
compatibility to existing data.

* put a HUGHE warning in the readme of pypgsql

So programmers are informed about the problems that could
accure using years and month statements in INTERVAL.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 19:57

Message:
Logged In: YES 
user_id=163326

Assigning to Billy, because I just don't get it:

This is WEIRD. It seems PostgreSQL remembers the years and
months. I always thought it might convert everything into
some base, say seconds internally.

Looks like it doesn't.

This might sound like a provocation, but here it goes: if
PostgreSQL isn't smart enough to convert, say a year to 365
days, I don't think we should try to be so smart.

A DateTimeDelta from mxDateTime is an exact timespan, not a
remember-the-user-input thingie like PostgreSQL's INTERVAL
seems to be.

So it's not possible to do an exact conversion from INTERVAL
to DateTimeDelta in all cases. Where it is possible, I think
it currently works.

My solution for the application programmer is to only use
days/hours/seconds when inserting values into an INTERVAL
column.

I'd be glad to hear your opinion on this.

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-22 16:53

Message:
Logged In: YES 
user_id=560817

I did some more testing:

$ python2.2
Python 2.2.2 (#1, Jan 18 2003, 10:18:59)
[GCC 3.2.2 20030109 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from mx import DateTime
>>> t = DateTime.DateTimeDelta(7300)
>>> t
<DateTimeDelta object for '7300:00:00:00.00' at 819a1c0>
>>> t.days
7300.0
>>>

test=> SELECT * FROM testint;
  inter
----------
 20 days
 20 years
 2 mons
 20 years
 14 days
(5 rows)
These are the values from the database for: 20 days, 20
years, 2 month, 2 decades, 2 weeks

test=> SET DATESTYLE TO NONEUROPEAN, GERMAN;
SET VARIABLE
test=> SELECT * FROM testint;
   inter
------------
 @ 20 days
 @ 20 years
 @ 2 mons
 @ 20 years
 @ 14 days
(5 rows)

mons and years are not supported by
PgSQL.TypeCache.interval2datetimedelta

Maybe you could convert them to the following values:
1 Month -> 30 days
3 Month -> 91 days (?)
6 Month -> 182 days (?)
12 Month -> 1 year
20 Month -> 1 year and 8 month
1 year -> 365 days
4 years -> 1461 days (4* 1 years + 1 day) (?)
400 years -> 146099 days (100 * 4 years - 1 day) (?)
2000 years -> 730496 (5* 400 years +1 day) (?)

Christian

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

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

[Pypgsql-devel] [ pypgsql-Feature Requests-708393 ] Moving to python2.2 new style classes and datetime

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

Feature Requests item #708393, was opened at 2003-03-23 16:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=366528&aid=708393&group_id=16528

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Christian Heimes (tiran)
Assigned to: Billy G. Allie (ballie01)
Summary: Moving to python2.2 new style classes and datetime

Initial Comment:
datetime:
http://www.python.org/dev/doc/devel/lib/module-datetime.html
new style classes:
http://www.python.org/doc/2.2.1/whatsnew/whatsnew22.html

Datetime will be a part of python2.3 and is used in zope3.

new style classes would ease up a lot of code, for example:

class PgInt8(long):
    pass

Christian

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

>Comment By: Christian Heimes (tiran)
Date: 2003-03-23 22:05

Message:
Logged In: YES 
user_id=560817

For datetime: For now there is only a python prototype of
the new upcoming Datetime module shipped with Zope3. I hope
Datetime will be backported to Python-2.2.

For numeric: Perhaps you should have a glance on pynum
(numerical python) utilities. Users who needs exact
numerical representation of numbers would have pynum
installed, so you can use the pynum classes. If it's not
installed then it seams so that the users don't need excat
values.

For int and float: For me I have to convert all special
pyPgSQL types into ordenary types like int, float and long
to use them in Zope3. This is due the security framework of
Zope3. Every class, schema or type must have an interface
which describes, what methods and attributes are public
(very easy speaking, see Zope3 WikiWikiWeb for more
informations). In my opinion this is a performance leak.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 21:11

Message:
Logged In: YES 
user_id=163326

For datetime: if there's an easily installable (read:
distutilified) Python package for Python 2.2, we might use
the Python datetime stuff in pyPgSQL 3.x instead of mxDateTime.

Yes, Python's int, long, float can handle all numbers that
PostgreSQL can handle in the corresponding types. But not
necessarily the other way round. For example, a PgInt2 has a
much smaller range than a Python int. Ditto for PgInt8 and
Python long.

So if you insert a (large) long in a INT8 column, you can
get an ERROR from the PostgreSQL side. That was why Billy
implemented the PgInt* types, so he told me.

I personally (currently) don't think they're worth the
effort, as they only catch a (possibly small) range of
errors. For example, there could still be additional
CONSTRAINTs.

We still need an equivalent of NUMERIC, though. And this one
is the only really hard type to implement.


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

Comment By: Christian Heimes (tiran)
Date: 2003-03-23 20:40

Message:
Logged In: YES 
user_id=560817

The new Datetime module for python2.3 is used under both
python2.2 and python2.3 in the upcoming Zope3. It's tested
and often used. By the way it would help me implementing a
database adapter in Zope3. :)

Do we really need range checks for numerical types? I thougt
python's int, long and float could handle all numbers that
could be handled by postgres (maybe except of numeric).

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 19:30

Message:
Logged In: YES 
user_id=163326

First, exploiting new-style classes and other Pyhton 2.3
features are  what pyPgSQL 3.0 is all about.

It will require Python 2.2, but I don't think we'll want to
use the new datetime module from 2.3.

Unfortunately, the pyPgSQL developers are generally short on
time, that's why not that much has been accomplished on the
3.0 front, yet. At least from me ;-)

If you're interested in other plans, you can look in the
TODO file, which is in CVS.

Also note that the current PgInt* classes do range checks.
Just subclassing from long doesn't get us this feature.

I'm still sceptical about the merit of the PgInt* types, but
that's just my personal opinion and better discussed on the
mailing list.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-708002 ] interval (DateTimeDelta) returns maximal days

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

Bugs item #708002, was opened at 2003-03-22 14:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=708002&group_id=16528

Category: PgSQL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Heimes (tiran)
Assigned to: Billy G. Allie (ballie01)
Summary: interval (DateTimeDelta) returns maximal days

Initial Comment:
I'm working on a pyPgSQLDA for Zope3 (see
http://cvs.zope.org/zopeproducts/pypgsqlda/). I have
noticed a problem mit time intervals.

INSERT INTO testinterval VALUES('20 years');
INSERT INTO testinterval VALUES('20 days');

pyPgSQL returns 20.0 days for both statements, what is
really strange becauce the interval type is 12bytes
long and supports more than a billion years.



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

>Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 21:55

Message:
Logged In: YES 
user_id=163326

This sounds like the best option.

If you could provide a patch, that'd be great :-)

This also sounds like another change that'd justify a bugfix
release.

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-23 21:50

Message:
Logged In: YES 
user_id=560817

I think the best way to get rid of this silly problems with
date and time would be changing the orbit of earth and using
the Napoleon Calender.  Who wants to write a proposal how to
do this?
</joke>

Why not supporting both ways so the user can chocie wether
he wants to convert years to 365.24 days or get an exception?

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 21:39

Message:
Logged In: YES 
user_id=163326

Alternatively, we could look wether only days/hours/... are
used in the string, then use the mxDateTime function to
parse it. Otherwise, raise an exception.

At least this wouldn't fail silently, returning a wrong value.

Thoughts?

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-23 20:26

Message:
Logged In: YES 
user_id=560817

I studied my Practical Postgres book from o'reily and found
an instresting information. A 'postgres year' are 365.24 days.

My opinion is:
* convert a year to 365.24 days
* convert a moth to 365.24/12 days

This is not an excat translation from year to days, but
better then converting the string "20 years" to 20 days. I
think it's the best workaround to keep backward
compatibility to existing data.

* put a HUGHE warning in the readme of pypgsql

So programmers are informed about the problems that could
accure using years and month statements in INTERVAL.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 19:57

Message:
Logged In: YES 
user_id=163326

Assigning to Billy, because I just don't get it:

This is WEIRD. It seems PostgreSQL remembers the years and
months. I always thought it might convert everything into
some base, say seconds internally.

Looks like it doesn't.

This might sound like a provocation, but here it goes: if
PostgreSQL isn't smart enough to convert, say a year to 365
days, I don't think we should try to be so smart.

A DateTimeDelta from mxDateTime is an exact timespan, not a
remember-the-user-input thingie like PostgreSQL's INTERVAL
seems to be.

So it's not possible to do an exact conversion from INTERVAL
to DateTimeDelta in all cases. Where it is possible, I think
it currently works.

My solution for the application programmer is to only use
days/hours/seconds when inserting values into an INTERVAL
column.

I'd be glad to hear your opinion on this.

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-22 16:53

Message:
Logged In: YES 
user_id=560817

I did some more testing:

$ python2.2
Python 2.2.2 (#1, Jan 18 2003, 10:18:59)
[GCC 3.2.2 20030109 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from mx import DateTime
>>> t = DateTime.DateTimeDelta(7300)
>>> t
<DateTimeDelta object for '7300:00:00:00.00' at 819a1c0>
>>> t.days
7300.0
>>>

test=> SELECT * FROM testint;
  inter
----------
 20 days
 20 years
 2 mons
 20 years
 14 days
(5 rows)
These are the values from the database for: 20 days, 20
years, 2 month, 2 decades, 2 weeks

test=> SET DATESTYLE TO NONEUROPEAN, GERMAN;
SET VARIABLE
test=> SELECT * FROM testint;
   inter
------------
 @ 20 days
 @ 20 years
 @ 2 mons
 @ 20 years
 @ 14 days
(5 rows)

mons and years are not supported by
PgSQL.TypeCache.interval2datetimedelta

Maybe you could convert them to the following values:
1 Month -> 30 days
3 Month -> 91 days (?)
6 Month -> 182 days (?)
12 Month -> 1 year
20 Month -> 1 year and 8 month
1 year -> 365 days
4 years -> 1461 days (4* 1 years + 1 day) (?)
400 years -> 146099 days (100 * 4 years - 1 day) (?)
2000 years -> 730496 (5* 400 years +1 day) (?)

Christian

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

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

[Pypgsql-devel] [ pypgsql-Bugs-708002 ] interval (DateTimeDelta) returns maximal days

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

Bugs item #708002, was opened at 2003-03-22 14:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=708002&group_id=16528

Category: PgSQL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Heimes (tiran)
Assigned to: Billy G. Allie (ballie01)
Summary: interval (DateTimeDelta) returns maximal days

Initial Comment:
I'm working on a pyPgSQLDA for Zope3 (see
http://cvs.zope.org/zopeproducts/pypgsqlda/). I have
noticed a problem mit time intervals.

INSERT INTO testinterval VALUES('20 years');
INSERT INTO testinterval VALUES('20 days');

pyPgSQL returns 20.0 days for both statements, what is
really strange becauce the interval type is 12bytes
long and supports more than a billion years.



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

>Comment By: Christian Heimes (tiran)
Date: 2003-03-23 21:50

Message:
Logged In: YES 
user_id=560817

I think the best way to get rid of this silly problems with
date and time would be changing the orbit of earth and using
the Napoleon Calender.  Who wants to write a proposal how to
do this?
</joke>

Why not supporting both ways so the user can chocie wether
he wants to convert years to 365.24 days or get an exception?

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 21:39

Message:
Logged In: YES 
user_id=163326

Alternatively, we could look wether only days/hours/... are
used in the string, then use the mxDateTime function to
parse it. Otherwise, raise an exception.

At least this wouldn't fail silently, returning a wrong value.

Thoughts?

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-23 20:26

Message:
Logged In: YES 
user_id=560817

I studied my Practical Postgres book from o'reily and found
an instresting information. A 'postgres year' are 365.24 days.

My opinion is:
* convert a year to 365.24 days
* convert a moth to 365.24/12 days

This is not an excat translation from year to days, but
better then converting the string "20 years" to 20 days. I
think it's the best workaround to keep backward
compatibility to existing data.

* put a HUGHE warning in the readme of pypgsql

So programmers are informed about the problems that could
accure using years and month statements in INTERVAL.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 19:57

Message:
Logged In: YES 
user_id=163326

Assigning to Billy, because I just don't get it:

This is WEIRD. It seems PostgreSQL remembers the years and
months. I always thought it might convert everything into
some base, say seconds internally.

Looks like it doesn't.

This might sound like a provocation, but here it goes: if
PostgreSQL isn't smart enough to convert, say a year to 365
days, I don't think we should try to be so smart.

A DateTimeDelta from mxDateTime is an exact timespan, not a
remember-the-user-input thingie like PostgreSQL's INTERVAL
seems to be.

So it's not possible to do an exact conversion from INTERVAL
to DateTimeDelta in all cases. Where it is possible, I think
it currently works.

My solution for the application programmer is to only use
days/hours/seconds when inserting values into an INTERVAL
column.

I'd be glad to hear your opinion on this.

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-22 16:53

Message:
Logged In: YES 
user_id=560817

I did some more testing:

$ python2.2
Python 2.2.2 (#1, Jan 18 2003, 10:18:59)
[GCC 3.2.2 20030109 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from mx import DateTime
>>> t = DateTime.DateTimeDelta(7300)
>>> t
<DateTimeDelta object for '7300:00:00:00.00' at 819a1c0>
>>> t.days
7300.0
>>>

test=> SELECT * FROM testint;
  inter
----------
 20 days
 20 years
 2 mons
 20 years
 14 days
(5 rows)
These are the values from the database for: 20 days, 20
years, 2 month, 2 decades, 2 weeks

test=> SET DATESTYLE TO NONEUROPEAN, GERMAN;
SET VARIABLE
test=> SELECT * FROM testint;
   inter
------------
 @ 20 days
 @ 20 years
 @ 2 mons
 @ 20 years
 @ 14 days
(5 rows)

mons and years are not supported by
PgSQL.TypeCache.interval2datetimedelta

Maybe you could convert them to the following values:
1 Month -> 30 days
3 Month -> 91 days (?)
6 Month -> 182 days (?)
12 Month -> 1 year
20 Month -> 1 year and 8 month
1 year -> 365 days
4 years -> 1461 days (4* 1 years + 1 day) (?)
400 years -> 146099 days (100 * 4 years - 1 day) (?)
2000 years -> 730496 (5* 400 years +1 day) (?)

Christian

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

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

[Pypgsql-devel] [ pypgsql-Bugs-708002 ] interval (DateTimeDelta) returns maximal days

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

Bugs item #708002, was opened at 2003-03-22 14:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=708002&group_id=16528

Category: PgSQL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Heimes (tiran)
Assigned to: Billy G. Allie (ballie01)
Summary: interval (DateTimeDelta) returns maximal days

Initial Comment:
I'm working on a pyPgSQLDA for Zope3 (see
http://cvs.zope.org/zopeproducts/pypgsqlda/). I have
noticed a problem mit time intervals.

INSERT INTO testinterval VALUES('20 years');
INSERT INTO testinterval VALUES('20 days');

pyPgSQL returns 20.0 days for both statements, what is
really strange becauce the interval type is 12bytes
long and supports more than a billion years.



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

>Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 21:39

Message:
Logged In: YES 
user_id=163326

Alternatively, we could look wether only days/hours/... are
used in the string, then use the mxDateTime function to
parse it. Otherwise, raise an exception.

At least this wouldn't fail silently, returning a wrong value.

Thoughts?

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-23 20:26

Message:
Logged In: YES 
user_id=560817

I studied my Practical Postgres book from o'reily and found
an instresting information. A 'postgres year' are 365.24 days.

My opinion is:
* convert a year to 365.24 days
* convert a moth to 365.24/12 days

This is not an excat translation from year to days, but
better then converting the string "20 years" to 20 days. I
think it's the best workaround to keep backward
compatibility to existing data.

* put a HUGHE warning in the readme of pypgsql

So programmers are informed about the problems that could
accure using years and month statements in INTERVAL.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 19:57

Message:
Logged In: YES 
user_id=163326

Assigning to Billy, because I just don't get it:

This is WEIRD. It seems PostgreSQL remembers the years and
months. I always thought it might convert everything into
some base, say seconds internally.

Looks like it doesn't.

This might sound like a provocation, but here it goes: if
PostgreSQL isn't smart enough to convert, say a year to 365
days, I don't think we should try to be so smart.

A DateTimeDelta from mxDateTime is an exact timespan, not a
remember-the-user-input thingie like PostgreSQL's INTERVAL
seems to be.

So it's not possible to do an exact conversion from INTERVAL
to DateTimeDelta in all cases. Where it is possible, I think
it currently works.

My solution for the application programmer is to only use
days/hours/seconds when inserting values into an INTERVAL
column.

I'd be glad to hear your opinion on this.

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-22 16:53

Message:
Logged In: YES 
user_id=560817

I did some more testing:

$ python2.2
Python 2.2.2 (#1, Jan 18 2003, 10:18:59)
[GCC 3.2.2 20030109 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from mx import DateTime
>>> t = DateTime.DateTimeDelta(7300)
>>> t
<DateTimeDelta object for '7300:00:00:00.00' at 819a1c0>
>>> t.days
7300.0
>>>

test=> SELECT * FROM testint;
  inter
----------
 20 days
 20 years
 2 mons
 20 years
 14 days
(5 rows)
These are the values from the database for: 20 days, 20
years, 2 month, 2 decades, 2 weeks

test=> SET DATESTYLE TO NONEUROPEAN, GERMAN;
SET VARIABLE
test=> SELECT * FROM testint;
   inter
------------
 @ 20 days
 @ 20 years
 @ 2 mons
 @ 20 years
 @ 14 days
(5 rows)

mons and years are not supported by
PgSQL.TypeCache.interval2datetimedelta

Maybe you could convert them to the following values:
1 Month -> 30 days
3 Month -> 91 days (?)
6 Month -> 182 days (?)
12 Month -> 1 year
20 Month -> 1 year and 8 month
1 year -> 365 days
4 years -> 1461 days (4* 1 years + 1 day) (?)
400 years -> 146099 days (100 * 4 years - 1 day) (?)
2000 years -> 730496 (5* 400 years +1 day) (?)

Christian

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

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

[Pypgsql-devel] [ pypgsql-Feature Requests-708393 ] Moving to python2.2 new style classes and datetime

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

Feature Requests item #708393, was opened at 2003-03-23 16:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=366528&aid=708393&group_id=16528

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Christian Heimes (tiran)
>Assigned to: Billy G. Allie (ballie01)
Summary: Moving to python2.2 new style classes and datetime

Initial Comment:
datetime:
http://www.python.org/dev/doc/devel/lib/module-datetime.html
new style classes:
http://www.python.org/doc/2.2.1/whatsnew/whatsnew22.html

Datetime will be a part of python2.3 and is used in zope3.

new style classes would ease up a lot of code, for example:

class PgInt8(long):
    pass

Christian

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

>Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 21:11

Message:
Logged In: YES 
user_id=163326

For datetime: if there's an easily installable (read:
distutilified) Python package for Python 2.2, we might use
the Python datetime stuff in pyPgSQL 3.x instead of mxDateTime.

Yes, Python's int, long, float can handle all numbers that
PostgreSQL can handle in the corresponding types. But not
necessarily the other way round. For example, a PgInt2 has a
much smaller range than a Python int. Ditto for PgInt8 and
Python long.

So if you insert a (large) long in a INT8 column, you can
get an ERROR from the PostgreSQL side. That was why Billy
implemented the PgInt* types, so he told me.

I personally (currently) don't think they're worth the
effort, as they only catch a (possibly small) range of
errors. For example, there could still be additional
CONSTRAINTs.

We still need an equivalent of NUMERIC, though. And this one
is the only really hard type to implement.


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

Comment By: Christian Heimes (tiran)
Date: 2003-03-23 20:40

Message:
Logged In: YES 
user_id=560817

The new Datetime module for python2.3 is used under both
python2.2 and python2.3 in the upcoming Zope3. It's tested
and often used. By the way it would help me implementing a
database adapter in Zope3. :)

Do we really need range checks for numerical types? I thougt
python's int, long and float could handle all numbers that
could be handled by postgres (maybe except of numeric).

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 19:30

Message:
Logged In: YES 
user_id=163326

First, exploiting new-style classes and other Pyhton 2.3
features are  what pyPgSQL 3.0 is all about.

It will require Python 2.2, but I don't think we'll want to
use the new datetime module from 2.3.

Unfortunately, the pyPgSQL developers are generally short on
time, that's why not that much has been accomplished on the
3.0 front, yet. At least from me ;-)

If you're interested in other plans, you can look in the
TODO file, which is in CVS.

Also note that the current PgInt* classes do range checks.
Just subclassing from long doesn't get us this feature.

I'm still sceptical about the merit of the PgInt* types, but
that's just my personal opinion and better discussed on the
mailing list.

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

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

[Pypgsql-devel] [ pypgsql-Feature Requests-708393 ] Moving to python2.2 new style classes and datetime

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

Feature Requests item #708393, was opened at 2003-03-23 16:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=366528&aid=708393&group_id=16528

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Moving to python2.2 new style classes and datetime

Initial Comment:
datetime:
http://www.python.org/dev/doc/devel/lib/module-datetime.html
new style classes:
http://www.python.org/doc/2.2.1/whatsnew/whatsnew22.html

Datetime will be a part of python2.3 and is used in zope3.

new style classes would ease up a lot of code, for example:

class PgInt8(long):
    pass

Christian

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

>Comment By: Christian Heimes (tiran)
Date: 2003-03-23 20:40

Message:
Logged In: YES 
user_id=560817

The new Datetime module for python2.3 is used under both
python2.2 and python2.3 in the upcoming Zope3. It's tested
and often used. By the way it would help me implementing a
database adapter in Zope3. :)

Do we really need range checks for numerical types? I thougt
python's int, long and float could handle all numbers that
could be handled by postgres (maybe except of numeric).

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 19:30

Message:
Logged In: YES 
user_id=163326

First, exploiting new-style classes and other Pyhton 2.3
features are  what pyPgSQL 3.0 is all about.

It will require Python 2.2, but I don't think we'll want to
use the new datetime module from 2.3.

Unfortunately, the pyPgSQL developers are generally short on
time, that's why not that much has been accomplished on the
3.0 front, yet. At least from me ;-)

If you're interested in other plans, you can look in the
TODO file, which is in CVS.

Also note that the current PgInt* classes do range checks.
Just subclassing from long doesn't get us this feature.

I'm still sceptical about the merit of the PgInt* types, but
that's just my personal opinion and better discussed on the
mailing list.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-708002 ] interval (DateTimeDelta) returns maximal days

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

Bugs item #708002, was opened at 2003-03-22 14:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=708002&group_id=16528

Category: PgSQL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Heimes (tiran)
Assigned to: Billy G. Allie (ballie01)
Summary: interval (DateTimeDelta) returns maximal days

Initial Comment:
I'm working on a pyPgSQLDA for Zope3 (see
http://cvs.zope.org/zopeproducts/pypgsqlda/). I have
noticed a problem mit time intervals.

INSERT INTO testinterval VALUES('20 years');
INSERT INTO testinterval VALUES('20 days');

pyPgSQL returns 20.0 days for both statements, what is
really strange becauce the interval type is 12bytes
long and supports more than a billion years.



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

>Comment By: Christian Heimes (tiran)
Date: 2003-03-23 20:26

Message:
Logged In: YES 
user_id=560817

I studied my Practical Postgres book from o'reily and found
an instresting information. A 'postgres year' are 365.24 days.

My opinion is:
* convert a year to 365.24 days
* convert a moth to 365.24/12 days

This is not an excat translation from year to days, but
better then converting the string "20 years" to 20 days. I
think it's the best workaround to keep backward
compatibility to existing data.

* put a HUGHE warning in the readme of pypgsql

So programmers are informed about the problems that could
accure using years and month statements in INTERVAL.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 19:57

Message:
Logged In: YES 
user_id=163326

Assigning to Billy, because I just don't get it:

This is WEIRD. It seems PostgreSQL remembers the years and
months. I always thought it might convert everything into
some base, say seconds internally.

Looks like it doesn't.

This might sound like a provocation, but here it goes: if
PostgreSQL isn't smart enough to convert, say a year to 365
days, I don't think we should try to be so smart.

A DateTimeDelta from mxDateTime is an exact timespan, not a
remember-the-user-input thingie like PostgreSQL's INTERVAL
seems to be.

So it's not possible to do an exact conversion from INTERVAL
to DateTimeDelta in all cases. Where it is possible, I think
it currently works.

My solution for the application programmer is to only use
days/hours/seconds when inserting values into an INTERVAL
column.

I'd be glad to hear your opinion on this.

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-22 16:53

Message:
Logged In: YES 
user_id=560817

I did some more testing:

$ python2.2
Python 2.2.2 (#1, Jan 18 2003, 10:18:59)
[GCC 3.2.2 20030109 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from mx import DateTime
>>> t = DateTime.DateTimeDelta(7300)
>>> t
<DateTimeDelta object for '7300:00:00:00.00' at 819a1c0>
>>> t.days
7300.0
>>>

test=> SELECT * FROM testint;
  inter
----------
 20 days
 20 years
 2 mons
 20 years
 14 days
(5 rows)
These are the values from the database for: 20 days, 20
years, 2 month, 2 decades, 2 weeks

test=> SET DATESTYLE TO NONEUROPEAN, GERMAN;
SET VARIABLE
test=> SELECT * FROM testint;
   inter
------------
 @ 20 days
 @ 20 years
 @ 2 mons
 @ 20 years
 @ 14 days
(5 rows)

mons and years are not supported by
PgSQL.TypeCache.interval2datetimedelta

Maybe you could convert them to the following values:
1 Month -> 30 days
3 Month -> 91 days (?)
6 Month -> 182 days (?)
12 Month -> 1 year
20 Month -> 1 year and 8 month
1 year -> 365 days
4 years -> 1461 days (4* 1 years + 1 day) (?)
400 years -> 146099 days (100 * 4 years - 1 day) (?)
2000 years -> 730496 (5* 400 years +1 day) (?)

Christian

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

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

[Pypgsql-devel] [ pypgsql-Bugs-708002 ] interval (DateTimeDelta) returns maximal days

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

Bugs item #708002, was opened at 2003-03-22 14:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=708002&group_id=16528

Category: PgSQL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Heimes (tiran)
>Assigned to: Billy G. Allie (ballie01)
Summary: interval (DateTimeDelta) returns maximal days

Initial Comment:
I'm working on a pyPgSQLDA for Zope3 (see
http://cvs.zope.org/zopeproducts/pypgsqlda/). I have
noticed a problem mit time intervals.

INSERT INTO testinterval VALUES('20 years');
INSERT INTO testinterval VALUES('20 days');

pyPgSQL returns 20.0 days for both statements, what is
really strange becauce the interval type is 12bytes
long and supports more than a billion years.



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

>Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 19:57

Message:
Logged In: YES 
user_id=163326

Assigning to Billy, because I just don't get it:

This is WEIRD. It seems PostgreSQL remembers the years and
months. I always thought it might convert everything into
some base, say seconds internally.

Looks like it doesn't.

This might sound like a provocation, but here it goes: if
PostgreSQL isn't smart enough to convert, say a year to 365
days, I don't think we should try to be so smart.

A DateTimeDelta from mxDateTime is an exact timespan, not a
remember-the-user-input thingie like PostgreSQL's INTERVAL
seems to be.

So it's not possible to do an exact conversion from INTERVAL
to DateTimeDelta in all cases. Where it is possible, I think
it currently works.

My solution for the application programmer is to only use
days/hours/seconds when inserting values into an INTERVAL
column.

I'd be glad to hear your opinion on this.

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

Comment By: Christian Heimes (tiran)
Date: 2003-03-22 16:53

Message:
Logged In: YES 
user_id=560817

I did some more testing:

$ python2.2
Python 2.2.2 (#1, Jan 18 2003, 10:18:59)
[GCC 3.2.2 20030109 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from mx import DateTime
>>> t = DateTime.DateTimeDelta(7300)
>>> t
<DateTimeDelta object for '7300:00:00:00.00' at 819a1c0>
>>> t.days
7300.0
>>>

test=> SELECT * FROM testint;
  inter
----------
 20 days
 20 years
 2 mons
 20 years
 14 days
(5 rows)
These are the values from the database for: 20 days, 20
years, 2 month, 2 decades, 2 weeks

test=> SET DATESTYLE TO NONEUROPEAN, GERMAN;
SET VARIABLE
test=> SELECT * FROM testint;
   inter
------------
 @ 20 days
 @ 20 years
 @ 2 mons
 @ 20 years
 @ 14 days
(5 rows)

mons and years are not supported by
PgSQL.TypeCache.interval2datetimedelta

Maybe you could convert them to the following values:
1 Month -> 30 days
3 Month -> 91 days (?)
6 Month -> 182 days (?)
12 Month -> 1 year
20 Month -> 1 year and 8 month
1 year -> 365 days
4 years -> 1461 days (4* 1 years + 1 day) (?)
400 years -> 146099 days (100 * 4 years - 1 day) (?)
2000 years -> 730496 (5* 400 years +1 day) (?)

Christian

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

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

[Pypgsql-devel] [ pypgsql-Bugs-708002 ] interval (DateTimeDelta) returns maximal days

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

Bugs item #708002, was opened at 2003-03-22 14:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=708002&group_id=16528

Category: PgSQL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Heimes (tiran)
>Assigned to: Gerhard Häring (ghaering)
Summary: interval (DateTimeDelta) returns maximal days

Initial Comment:
I'm working on a pyPgSQLDA for Zope3 (see
http://cvs.zope.org/zopeproducts/pypgsqlda/). I have
noticed a problem mit time intervals.

INSERT INTO testinterval VALUES('20 years');
INSERT INTO testinterval VALUES('20 days');

pyPgSQL returns 20.0 days for both statements, what is
really strange becauce the interval type is 12bytes
long and supports more than a billion years.



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

Comment By: Christian Heimes (tiran)
Date: 2003-03-22 16:53

Message:
Logged In: YES 
user_id=560817

I did some more testing:

$ python2.2
Python 2.2.2 (#1, Jan 18 2003, 10:18:59)
[GCC 3.2.2 20030109 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from mx import DateTime
>>> t = DateTime.DateTimeDelta(7300)
>>> t
<DateTimeDelta object for '7300:00:00:00.00' at 819a1c0>
>>> t.days
7300.0
>>>

test=> SELECT * FROM testint;
  inter
----------
 20 days
 20 years
 2 mons
 20 years
 14 days
(5 rows)
These are the values from the database for: 20 days, 20
years, 2 month, 2 decades, 2 weeks

test=> SET DATESTYLE TO NONEUROPEAN, GERMAN;
SET VARIABLE
test=> SELECT * FROM testint;
   inter
------------
 @ 20 days
 @ 20 years
 @ 2 mons
 @ 20 years
 @ 14 days
(5 rows)

mons and years are not supported by
PgSQL.TypeCache.interval2datetimedelta

Maybe you could convert them to the following values:
1 Month -> 30 days
3 Month -> 91 days (?)
6 Month -> 182 days (?)
12 Month -> 1 year
20 Month -> 1 year and 8 month
1 year -> 365 days
4 years -> 1461 days (4* 1 years + 1 day) (?)
400 years -> 146099 days (100 * 4 years - 1 day) (?)
2000 years -> 730496 (5* 400 years +1 day) (?)

Christian

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

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

[Pypgsql-devel] [ pypgsql-Feature Requests-708393 ] Moving to python2.2 new style classes and datetime

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

Feature Requests item #708393, was opened at 2003-03-23 16:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=366528&aid=708393&group_id=16528

Category: None
Group: None
Status: Open
>Priority: 3
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Moving to python2.2 new style classes and datetime

Initial Comment:
datetime:
http://www.python.org/dev/doc/devel/lib/module-datetime.html
new style classes:
http://www.python.org/doc/2.2.1/whatsnew/whatsnew22.html

Datetime will be a part of python2.3 and is used in zope3.

new style classes would ease up a lot of code, for example:

class PgInt8(long):
    pass

Christian

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

>Comment By: Gerhard Häring (ghaering)
Date: 2003-03-23 19:30

Message:
Logged In: YES 
user_id=163326

First, exploiting new-style classes and other Pyhton 2.3
features are  what pyPgSQL 3.0 is all about.

It will require Python 2.2, but I don't think we'll want to
use the new datetime module from 2.3.

Unfortunately, the pyPgSQL developers are generally short on
time, that's why not that much has been accomplished on the
3.0 front, yet. At least from me ;-)

If you're interested in other plans, you can look in the
TODO file, which is in CVS.

Also note that the current PgInt* classes do range checks.
Just subclassing from long doesn't get us this feature.

I'm still sceptical about the merit of the PgInt* types, but
that's just my personal opinion and better discussed on the
mailing list.

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

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

[Pypgsql-devel] [ pypgsql-Feature Requests-708393 ] Moving to python2.2 new style classes and datetime

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

Feature Requests item #708393, was opened at 2003-03-23 16:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=366528&aid=708393&group_id=16528

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Moving to python2.2 new style classes and datetime

Initial Comment:
datetime:
http://www.python.org/dev/doc/devel/lib/module-datetime.html
new style classes:
http://www.python.org/doc/2.2.1/whatsnew/whatsnew22.html

Datetime will be a part of python2.3 and is used in zope3.

new style classes would ease up a lot of code, for example:

class PgInt8(long):
    pass

Christian

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

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

[Pypgsql-devel] [ pypgsql-Bugs-708002 ] interval (DateTimeDelta) returns maximal days

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

Bugs item #708002, was opened at 2003-03-22 14:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=708002&group_id=16528

Category: PgSQL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: interval (DateTimeDelta) returns maximal days

Initial Comment:
I'm working on a pyPgSQLDA for Zope3 (see
http://cvs.zope.org/zopeproducts/pypgsqlda/). I have
noticed a problem mit time intervals.

INSERT INTO testinterval VALUES('20 years');
INSERT INTO testinterval VALUES('20 days');

pyPgSQL returns 20.0 days for both statements, what is
really strange becauce the interval type is 12bytes
long and supports more than a billion years.



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

>Comment By: Christian Heimes (tiran)
Date: 2003-03-22 16:53

Message:
Logged In: YES 
user_id=560817

I did some more testing:

$ python2.2
Python 2.2.2 (#1, Jan 18 2003, 10:18:59)
[GCC 3.2.2 20030109 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from mx import DateTime
>>> t = DateTime.DateTimeDelta(7300)
>>> t
<DateTimeDelta object for '7300:00:00:00.00' at 819a1c0>
>>> t.days
7300.0
>>>

test=> SELECT * FROM testint;
  inter
----------
 20 days
 20 years
 2 mons
 20 years
 14 days
(5 rows)
These are the values from the database for: 20 days, 20
years, 2 month, 2 decades, 2 weeks

test=> SET DATESTYLE TO NONEUROPEAN, GERMAN;
SET VARIABLE
test=> SELECT * FROM testint;
   inter
------------
 @ 20 days
 @ 20 years
 @ 2 mons
 @ 20 years
 @ 14 days
(5 rows)

mons and years are not supported by
PgSQL.TypeCache.interval2datetimedelta

Maybe you could convert them to the following values:
1 Month -> 30 days
3 Month -> 91 days (?)
6 Month -> 182 days (?)
12 Month -> 1 year
20 Month -> 1 year and 8 month
1 year -> 365 days
4 years -> 1461 days (4* 1 years + 1 day) (?)
400 years -> 146099 days (100 * 4 years - 1 day) (?)
2000 years -> 730496 (5* 400 years +1 day) (?)

Christian

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

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

[Pypgsql-devel] [ pypgsql-Patches-708013 ] type of PG_TIMETZ is NoneType instead timetz

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

Patches item #708013, was opened at 2003-03-22 14:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=708013&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Heimes (tiran)
>Assigned to: Gerhard Häring (ghaering)
Summary: type of PG_TIMETZ is NoneType instead timetz

Initial Comment:
I'm working on a DA for Zope3 (see
http://cvs.zope.org/zopeproducts/pypgsqlda/ and last
posting). The database abstraction layer of Zope3
supports converter to zope3 types by the type of
column. PG_TIMETZ has no corresponding typechar.

There should be a line like this in libpqmodule.c:
case PG_TIMETZ:		desc = "timetz";		break;

greetings
Christian

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

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

[Pypgsql-devel] [ pypgsql-Patches-708013 ] type of PG_TIMETZ is NoneType instead timetz

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

Patches item #708013, was opened at 2003-03-22 14:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=708013&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: type of PG_TIMETZ is NoneType instead timetz

Initial Comment:
I'm working on a DA for Zope3 (see
http://cvs.zope.org/zopeproducts/pypgsqlda/ and last
posting). The database abstraction layer of Zope3
supports converter to zope3 types by the type of
column. PG_TIMETZ has no corresponding typechar.

There should be a line like this in libpqmodule.c:
case PG_TIMETZ:		desc = "timetz";		break;

greetings
Christian

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

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

[Pypgsql-devel] [ pypgsql-Bugs-708002 ] interval (DateTimeDelta) returns maximal days

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

Bugs item #708002, was opened at 2003-03-22 14:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=708002&group_id=16528

Category: PgSQL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: interval (DateTimeDelta) returns maximal days

Initial Comment:
I'm working on a pyPgSQLDA for Zope3 (see
http://cvs.zope.org/zopeproducts/pypgsqlda/). I have
noticed a problem mit time intervals.

INSERT INTO testinterval VALUES('20 years');
INSERT INTO testinterval VALUES('20 days');

pyPgSQL returns 20.0 days for both statements, what is
really strange becauce the interval type is 12bytes
long and supports more than a billion years.



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

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

[Pypgsql-devel] [ pypgsql-Bugs-698981 ] Does not quote portal names to close them properly

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

Bugs item #698981, was opened at 2003-03-06 15:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=698981&group_id=16528

Category: PgSQL
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Phil Gregory (phil_g)
>Assigned to: Billy G. Allie (ballie01)
Summary: Does not quote portal names to close them properly

Initial Comment:
When PyPgSQL opens and uses portals, the SQL statements
use mixed-case names for the portals, placing them in
double quotes.  However, when the portals are closed
the double quotes are not used, so PostgreSQL treats
the names as all lower-case.  This leads to lots of
open portals being left on the server as well as
messages like

WARNING:  PerformPortalClose: portal "pgsql_08311b04"
not found

appearing in the logs.

Sample session:

Python 2.2.2 (#1, Jan 18 2003, 10:18:59)
[GCC 3.2.2 20030109 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> from pyPgSQL import PgSQL
>>> con = PgSQL.connect(host = "aragorn", user =
"phil", database = "moobot")
>>> con.conn.toggleShowQuery
'On'
>>> cursor = con.cursor()
QUERY: BEGIN WORK
>>> cursor.execute("SELECT * FROM data")
QUERY: DECLARE "PgSQL_0818F0AC" CURSOR FOR SELECT *
FROM data
QUERY: FETCH 1 FROM "PgSQL_0818F0AC"
QUERY: SELECT typname, -1 , typelem FROM pg_type WHERE
oid = 1043
>>> result = cursor.fetchmany(3)
QUERY: FETCH 2 FROM "PgSQL_0818F0AC"
>>> con.commit()
QUERY: CLOSE PgSQL_0818F0AC
QUERY: COMMIT WORK
>>>

And, from the logs:

WARNING:  PerformPortalClose: portal "pgsql_0818f0ac"
not found

Note that the case of the portal name does not match.

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

>Comment By: Billy G. Allie (ballie01)
Date: 2003-03-07 01:59

Message:
Logged In: YES 
user_id=8500

This problem has already been fixed.  You can get PgSQL.py
from the CVS repository to obtain the fix for this problem
(and others).

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

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

[Pypgsql-devel] [ pypgsql-Bugs-697221 ] OverflowError: value too large for PgNumeric

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

Bugs item #697221, was opened at 2003-03-04 07:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=697221&group_id=16528

Category: PgNumeric
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 7
Submitted By: Michael Howitz (icemac)
Assigned to: Nobody/Anonymous (nobody)
Summary: OverflowError: value too large for PgNumeric

Initial Comment:
I create a table:

CREATE TABLE test_bug (
  t NUMERIC(10,2)
);

Then I insert two values:
INSERT INTO test_bug VALUES (24.11);
INSERT INTO test_bug VALUES (305.03);

Now I query the values through ZOPE using:
SELECT t FROM test_bug
UNION SELECT 0
ORDER BY t ASC

The result is: 
OverflowError: value too large for PgNumeric

Traceback (innermost last):
    * Module ZPublisher.Publish, line 98, in publish
    * Module ZPublisher.mapply, line 88, in mapply
    * Module ZPublisher.Publish, line 39, in call_object
    * Module Shared.DC.ZRDB.DA, line 331, in manage_test
    * Module Shared.DC.ZRDB.DA, line 309, in manage_test
    * Module Shared.DC.ZRDB.DA, line 443, in __call__
    * Module Products.ZpyPgSQLDA.db, line 148, in query
    * Module pyPgSQL.PgSQL, line 3074, in fetchmany
    * Module pyPgSQL.PgSQL, line 2688, in __fetchManyRows
    * Module pyPgSQL.PgSQL, line 2664, in __fetchOneRow
    * Module pyPgSQL.PgSQL, line 719, in typecast
    * Module pyPgSQL.PgSQL, line 1336, in __init__


The Exception does not happen, when I leave out the
UNION-statment (but I need it) or if I order by desc
(but this is no solution).

It seems that the precision for the column is computed
as the precision of the first value.

my Versions:
Zope Version: (unreleased version, python 2.2.2, linux2)
Python Version: 2.2.2 (#3, Dec 15 2002, 15:08:50) [GCC
2.95.4 20011002 (Debian prerelease)] 

I use ZpyPgSQLDA.

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

>Comment By: Billy G. Allie (ballie01)
Date: 2003-03-07 01:48

Message:
Logged In: YES 
user_id=8500

The problem has to do with the way that PostgreSQL returns
scale and precision information.  The 0 (from the union
select 0) does not have any scale or precision associated
with it, causing PgSQL to give a precision of 1 and a scale
of 0.  Since this was the first item in the result set, the
precision and scale in the crsor.description was set to 1
and 0 (which is wrong, it should be 10 and 2).

There is no way to fix the problem due to the way that
postgreSQL is returning the precision and scale, but a
work-around can and is implemented in version 1.32 of
PgSQL.py.  If the conversion to a PgNumeric fails in the
typecasting routine, the value is re-cast into a PgNumeric
without tusing the precision and scale from the
cursor.descrioption apptribute.

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

Comment By: Michael Howitz (icemac)
Date: 2003-03-04 07:53

Message:
Logged In: YES 
user_id=725802

I forgot to mention my version of pyPgSQL:
__version__ = "2.3"

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

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

[Pypgsql-devel] [ pypgsql-Bugs-694358 ] Buggy __radd__ in PgNumeric

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

Bugs item #694358, was opened at 2003-02-27 08:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=694358&group_id=16528

Category: PgNumeric
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Billy G. Allie (ballie01)
Summary: Buggy __radd__ in PgNumeric

Initial Comment:
[vivek kumar sent this to DB-SIG]

hi all,

I am sending this mail at this address coz i was unable
to find some address for reporting possible bug in
pyPgSQL and the
+pyPgSQL project page was not opening (slow net speed).

This may be a bug left in the pyPgSQL version 2.3. When
i try to add some numeric data returned by query
(PgNumeric) then it
+gives me name error (global __add__ not found). The
actual code for the __radd__ in PgNumeric was

def __radd__(self,other):
    return __add__(self,other)

A possible work around (it worked for me) may be

def __radd__(self,other):
    return self.__add__(other)

regards
vivek kumar

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

>Comment By: Billy G. Allie (ballie01)
Date: 2003-03-07 01:39

Message:
Logged In: YES 
user_id=8500

This bug is squashed in version 1.32 of PgSQL.py.

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

Comment By: Vivek Kumar (gupt_vive)
Date: 2003-03-07 01:14

Message:
Logged In: YES 
user_id=695184

dear sir,

In your follow up u have given the code
>3+PgNumeric("-5.0")

in the __add__ function the last line returns
>return PgNumeric((_s + _o), (mp + ms), ms)

the __init__code
>__init__(self, value, prec=None, scale=None)

In this case:
the value goes -20 and precision goes 2 

in __init__ function
>self.__v = value
and 
>_v = str(value)
so here _v becomes "-20"

now also 
>if len(_v) > prec: # here len(_v)=3 and prec=2
>         raise OverflowError, "value too large for PgNumeric"

so here it returns the OverflowError , as mentioned in your 
follow up.

May be the code should first check for negative/positive 
values before checking for the value length and precision..

regards
Vivek Kumar

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

Comment By: Vivek Kumar (gupt_vive)
Date: 2003-03-07 01:13

Message:
Logged In: YES 
user_id=695184

dear sir,

In your follow up u have given the code
>3+PgNumeric("-5.0")

in the __add__ function the last line returns
>return PgNumeric((_s + _o), (mp + ms), ms)

the __init__code
>__init__(self, value, prec=None, scale=None)

In this case:
the value goes -20 and precision goes 2 

in __init__ function
>self.__v = value
and 
>_v = str(value)
so here _v becomes "-20"

now also 
>if len(_v) > prec: # here len(_v)=3 and prec=2
>         raise OverflowError, "value too large for PgNumeric"

so here it returns the OverflowError , as mentioned in your 
follow up.

May be the code should first check for negative/positive 
values before checking for the value length and precision..

regards
Vivek Kumar

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-02 06:40

Message:
Logged In: YES 
user_id=163326

Billy, would you like to take a look at this one? I'm quite
puzzled with the workings of PgNumeric.

Once the obvious bug (self in wrong place) is fixed, there's
more  that doesn't work:

>>> 3 + PgNumeric("-5.0")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "pyPgSQL/PgSQL.py", line 1495, in __radd__
    return self.__add__(other)
  File "pyPgSQL/PgSQL.py", line 1492, in __add__
    return PgNumeric((_s + _o), (mp + ms), ms)
  File "pyPgSQL/PgSQL.py", line 1262, in __init__
    raise OverflowError, "value too large for PgNumeric"
OverflowError: value too large for PgNumeric

__rsub__ seems to be problematic, too.



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

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

[Pypgsql-devel] [ pypgsql-Bugs-694358 ] Buggy __radd__ in PgNumeric

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

Bugs item #694358, was opened at 2003-02-27 18:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=694358&group_id=16528

Category: PgNumeric
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Billy G. Allie (ballie01)
Summary: Buggy __radd__ in PgNumeric

Initial Comment:
[vivek kumar sent this to DB-SIG]

hi all,

I am sending this mail at this address coz i was unable
to find some address for reporting possible bug in
pyPgSQL and the
+pyPgSQL project page was not opening (slow net speed).

This may be a bug left in the pyPgSQL version 2.3. When
i try to add some numeric data returned by query
(PgNumeric) then it
+gives me name error (global __add__ not found). The
actual code for the __radd__ in PgNumeric was

def __radd__(self,other):
    return __add__(self,other)

A possible work around (it worked for me) may be

def __radd__(self,other):
    return self.__add__(other)

regards
vivek kumar

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

Comment By: Vivek Kumar (gupt_vive)
Date: 2003-03-07 11:14

Message:
Logged In: YES 
user_id=695184

dear sir,

In your follow up u have given the code
>3+PgNumeric("-5.0")

in the __add__ function the last line returns
>return PgNumeric((_s + _o), (mp + ms), ms)

the __init__code
>__init__(self, value, prec=None, scale=None)

In this case:
the value goes -20 and precision goes 2 

in __init__ function
>self.__v = value
and 
>_v = str(value)
so here _v becomes "-20"

now also 
>if len(_v) > prec: # here len(_v)=3 and prec=2
>         raise OverflowError, "value too large for PgNumeric"

so here it returns the OverflowError , as mentioned in your 
follow up.

May be the code should first check for negative/positive 
values before checking for the value length and precision..

regards
Vivek Kumar

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

Comment By: Vivek Kumar (gupt_vive)
Date: 2003-03-07 11:13

Message:
Logged In: YES 
user_id=695184

dear sir,

In your follow up u have given the code
>3+PgNumeric("-5.0")

in the __add__ function the last line returns
>return PgNumeric((_s + _o), (mp + ms), ms)

the __init__code
>__init__(self, value, prec=None, scale=None)

In this case:
the value goes -20 and precision goes 2 

in __init__ function
>self.__v = value
and 
>_v = str(value)
so here _v becomes "-20"

now also 
>if len(_v) > prec: # here len(_v)=3 and prec=2
>         raise OverflowError, "value too large for PgNumeric"

so here it returns the OverflowError , as mentioned in your 
follow up.

May be the code should first check for negative/positive 
values before checking for the value length and precision..

regards
Vivek Kumar

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-02 16:40

Message:
Logged In: YES 
user_id=163326

Billy, would you like to take a look at this one? I'm quite
puzzled with the workings of PgNumeric.

Once the obvious bug (self in wrong place) is fixed, there's
more  that doesn't work:

>>> 3 + PgNumeric("-5.0")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "pyPgSQL/PgSQL.py", line 1495, in __radd__
    return self.__add__(other)
  File "pyPgSQL/PgSQL.py", line 1492, in __add__
    return PgNumeric((_s + _o), (mp + ms), ms)
  File "pyPgSQL/PgSQL.py", line 1262, in __init__
    raise OverflowError, "value too large for PgNumeric"
OverflowError: value too large for PgNumeric

__rsub__ seems to be problematic, too.



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

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

[Pypgsql-devel] [ pypgsql-Bugs-694358 ] Buggy __radd__ in PgNumeric

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

Bugs item #694358, was opened at 2003-02-27 18:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=694358&group_id=16528

Category: PgNumeric
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Billy G. Allie (ballie01)
Summary: Buggy __radd__ in PgNumeric

Initial Comment:
[vivek kumar sent this to DB-SIG]

hi all,

I am sending this mail at this address coz i was unable
to find some address for reporting possible bug in
pyPgSQL and the
+pyPgSQL project page was not opening (slow net speed).

This may be a bug left in the pyPgSQL version 2.3. When
i try to add some numeric data returned by query
(PgNumeric) then it
+gives me name error (global __add__ not found). The
actual code for the __radd__ in PgNumeric was

def __radd__(self,other):
    return __add__(self,other)

A possible work around (it worked for me) may be

def __radd__(self,other):
    return self.__add__(other)

regards
vivek kumar

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

Comment By: Vivek Kumar (gupt_vive)
Date: 2003-03-07 11:13

Message:
Logged In: YES 
user_id=695184

dear sir,

In your follow up u have given the code
>3+PgNumeric("-5.0")

in the __add__ function the last line returns
>return PgNumeric((_s + _o), (mp + ms), ms)

the __init__code
>__init__(self, value, prec=None, scale=None)

In this case:
the value goes -20 and precision goes 2 

in __init__ function
>self.__v = value
and 
>_v = str(value)
so here _v becomes "-20"

now also 
>if len(_v) > prec: # here len(_v)=3 and prec=2
>         raise OverflowError, "value too large for PgNumeric"

so here it returns the OverflowError , as mentioned in your 
follow up.

May be the code should first check for negative/positive 
values before checking for the value length and precision..

regards
Vivek Kumar

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-02 16:40

Message:
Logged In: YES 
user_id=163326

Billy, would you like to take a look at this one? I'm quite
puzzled with the workings of PgNumeric.

Once the obvious bug (self in wrong place) is fixed, there's
more  that doesn't work:

>>> 3 + PgNumeric("-5.0")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "pyPgSQL/PgSQL.py", line 1495, in __radd__
    return self.__add__(other)
  File "pyPgSQL/PgSQL.py", line 1492, in __add__
    return PgNumeric((_s + _o), (mp + ms), ms)
  File "pyPgSQL/PgSQL.py", line 1262, in __init__
    raise OverflowError, "value too large for PgNumeric"
OverflowError: value too large for PgNumeric

__rsub__ seems to be problematic, too.



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

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

[Pypgsql-devel] [ pypgsql-Bugs-698981 ] Does not quote portal names to close them properly

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

Bugs item #698981, was opened at 2003-03-06 15:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=698981&group_id=16528

Category: PgSQL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Phil Gregory (phil_g)
Assigned to: Nobody/Anonymous (nobody)
Summary: Does not quote portal names to close them properly

Initial Comment:
When PyPgSQL opens and uses portals, the SQL statements
use mixed-case names for the portals, placing them in
double quotes.  However, when the portals are closed
the double quotes are not used, so PostgreSQL treats
the names as all lower-case.  This leads to lots of
open portals being left on the server as well as
messages like

WARNING:  PerformPortalClose: portal "pgsql_08311b04"
not found

appearing in the logs.

Sample session:

Python 2.2.2 (#1, Jan 18 2003, 10:18:59)
[GCC 3.2.2 20030109 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> from pyPgSQL import PgSQL
>>> con = PgSQL.connect(host = "aragorn", user =
"phil", database = "moobot")
>>> con.conn.toggleShowQuery
'On'
>>> cursor = con.cursor()
QUERY: BEGIN WORK
>>> cursor.execute("SELECT * FROM data")
QUERY: DECLARE "PgSQL_0818F0AC" CURSOR FOR SELECT *
FROM data
QUERY: FETCH 1 FROM "PgSQL_0818F0AC"
QUERY: SELECT typname, -1 , typelem FROM pg_type WHERE
oid = 1043
>>> result = cursor.fetchmany(3)
QUERY: FETCH 2 FROM "PgSQL_0818F0AC"
>>> con.commit()
QUERY: CLOSE PgSQL_0818F0AC
QUERY: COMMIT WORK
>>>

And, from the logs:

WARNING:  PerformPortalClose: portal "pgsql_0818f0ac"
not found

Note that the case of the portal name does not match.

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

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

[Pypgsql-devel] [ pypgsql-Bugs-697221 ] OverflowError: value too large for PgNumeric

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

Bugs item #697221, was opened at 2003-03-04 13:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=697221&group_id=16528

Category: PgNumeric
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Howitz (icemac)
Assigned to: Nobody/Anonymous (nobody)
Summary: OverflowError: value too large for PgNumeric

Initial Comment:
I create a table:

CREATE TABLE test_bug (
  t NUMERIC(10,2)
);

Then I insert two values:
INSERT INTO test_bug VALUES (24.11);
INSERT INTO test_bug VALUES (305.03);

Now I query the values through ZOPE using:
SELECT t FROM test_bug
UNION SELECT 0
ORDER BY t ASC

The result is: 
OverflowError: value too large for PgNumeric

Traceback (innermost last):
    * Module ZPublisher.Publish, line 98, in publish
    * Module ZPublisher.mapply, line 88, in mapply
    * Module ZPublisher.Publish, line 39, in call_object
    * Module Shared.DC.ZRDB.DA, line 331, in manage_test
    * Module Shared.DC.ZRDB.DA, line 309, in manage_test
    * Module Shared.DC.ZRDB.DA, line 443, in __call__
    * Module Products.ZpyPgSQLDA.db, line 148, in query
    * Module pyPgSQL.PgSQL, line 3074, in fetchmany
    * Module pyPgSQL.PgSQL, line 2688, in __fetchManyRows
    * Module pyPgSQL.PgSQL, line 2664, in __fetchOneRow
    * Module pyPgSQL.PgSQL, line 719, in typecast
    * Module pyPgSQL.PgSQL, line 1336, in __init__


The Exception does not happen, when I leave out the
UNION-statment (but I need it) or if I order by desc
(but this is no solution).

It seems that the precision for the column is computed
as the precision of the first value.

my Versions:
Zope Version: (unreleased version, python 2.2.2, linux2)
Python Version: 2.2.2 (#3, Dec 15 2002, 15:08:50) [GCC
2.95.4 20011002 (Debian prerelease)] 

I use ZpyPgSQLDA.

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

>Comment By: Michael Howitz (icemac)
Date: 2003-03-04 13:53

Message:
Logged In: YES 
user_id=725802

I forgot to mention my version of pyPgSQL:
__version__ = "2.3"

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

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