pypgsql-users

[Pypgsql-users] How important is Python 2.1 compatibility?

[Billy G. A. <Bil...@mu...>]

Now that Python 2.2.x has been out for a while, I would like to find out how 
important Python 2.1 compatibility is.  There are a number of new features in 
Python 2.2.x that would make things in pyPgSQL cleaner, easier, etc., but of 
course using those features would not work with earlier version of Python.

I would like to conduct a poll of the user community to decide on one of two 
courses of action:

1.  Should pyPgSQL drop compatibility with versions of Python previous to 
version 2.2?

2.  Should we start a new branch that drops compatibility with previous 
versions and maintain the 2.x branch (bug fixes only) to provide 2.0 and 2.1 
compatibility?

Personally, I'm in favor of option 1, but I will support whichever option is 
chosen by the user community.

I look forward to you input.
-- 
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |

Re: [Pypgsql-users] How important is Python 2.1 compatibility?

[Tom J. <tje...@de...>]

Well Zope 2.x does not run with python 2.2

On Thu, 2002-06-06 at 00:00, Billy G. Allie wrote:
> Now that Python 2.2.x has been out for a while, I would like to find out
> how 
> important Python 2.1 compatibility is.  There are a number of new
> features in 
> Python 2.2.x that would make things in pyPgSQL cleaner, easier, etc.,
> but of 
> course using those features would not work with earlier version of
> Python.
> 
> I would like to conduct a poll of the user community to decide on one of
> two 
> courses of action:
> 
> 1.  Should pyPgSQL drop compatibility with versions of Python previous
> to 
> version 2.2?
> 
> 2.  Should we start a new branch that drops compatibility with previous 
> versions and maintain the 2.x branch (bug fixes only) to provide 2.0 and
> 2.1 
> compatibility?
> 
> Personally, I'm in favor of option 1, but I will support whichever
> option is 
> chosen by the user community.
> 
> I look forward to you input.
> -- 
> ____       | Billy G. Allie    | Domain....: Bil...@mu...
> |  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
> |-/-|----- | Dearborn, MI 48126|
> |/  |LLIE  | (313) 582-1540    |
> 
> 
-- 

Tom Jenkins
Development InfoStructure
http://www.devis.com

Re: [Pypgsql-users] How important is Python 2.1 compatibility?

[Gerhard <ger...@gm...>]

* Tom Jenkins <tje...@de...> [2002-06-05 23:57 -0400]:
> Well Zope 2.x does not run with python 2.2

Btw. the ZpyPgSQLDA in CVS isn't meant for serious use, yet. It hasn't
been worked on since its initial putting into CVS.

Or is anybody using pyPgSQL itself with Zope?

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: [Pypgsql-users] How important is Python 2.1 compatibility?

[Michael W. <wa...@tr...>]

At 12:00 AM 6/6/2002 -0400, Billy G. Allie wrote:
>1.  Should pyPgSQL drop compatibility with versions of Python previous to
>version 2.2?

I'm ok with option 1, support 2.2 and on only.

A normally silent pyPgSQL user...

[Pypgsql-users] Cursor.move and number of rows in cursors

[Gerhard <ger...@gm...>]

In a current project, I needed to wrap the PostgreSQL SQL extension MOVE
FORWARD/BACKWARD to move in server-side cursors. I'd suggest to add the
following method to the Cursor class:

    def move(self, howmany)

where howmany can be a positive or negative number, which controls
wether the cursor is moved backward or forward. Comments?

One other thing for the PostgreSQL experts (ehem): am I correct that
there is no way of knowing how many rows a cursor contains? Is it really
the easiest solution to first do a SELECT COUNT on the same query?

I can imagine there might be a hack with moving forward/backward by
variying values to examine the number of rows in the cursor. Or is there
a clean solution that I'm missing?

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: [Pypgsql-users] Cursor.move and number of rows in cursors

[Gerhard <ger...@gm...>]

* Gerhard Häring <ger...@gm...> [2002-06-07 20:35 +0200]:
> In a current project, I needed to wrap the PostgreSQL SQL extension MOVE
> FORWARD/BACKWARD to move in server-side cursors. I'd suggest to add the
> following method to the Cursor class:
> 
>     def move(self, howmany)

It think better to implement the optional DB-API extension Cursor Method
.scroll(value[,mode='relative']) from PEP 0249.

> One other thing for the PostgreSQL experts (ehem): am I correct that
> there is no way of knowing how many rows a cursor contains? Is it really
> the easiest solution to first do a SELECT COUNT on the same query?

Looks like so, but in the end I was able to do without knowing the total
number of rows.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: [Pypgsql-users] Cursor.move and number of rows in cursors

[Adam B. <ad...@po...>]

> > One other thing for the PostgreSQL experts (ehem): am I correct that
> > there is no way of knowing how many rows a cursor contains? Is it really
> > the easiest solution to first do a SELECT COUNT on the same query?
> Looks like so, but in the end I was able to do without knowing the total
> number of rows.

I'm not an expert, but I think that even PostgreSQL itself doesn't
know the number of rows before all of them are fetched.  Look at files
at src/backend/executor directory, especially execMain.c and
execProcnode.c.  The main fetching loop is in ExecutePlan() function,
which fetches rows one by one till ExecProcNode() returns nothing.
PostgreSQL portals simply don't execute more than it is necessary to
get the needed number of rows, whatever is the source of the data (a
table, a view or even a SRF -- a "set returning function").

Regards,

-- 
Adam Buraczewski <ad...@po...> * Linux registered user #165585
GCS/TW d- s-:+>+:- a- C+++(++++) UL++++$ P++ L++++ E++ W+ N++ o? K? w--
O M- V- PS+ !PE Y PGP+ t+ 5 X+ R tv- b+ DI? D G++ e+++>++++ h r+>++ y?

Re: [Pypgsql-users] How important is Python 2.1 compatibility?

[Adam B. <ad...@po...>]

Hallo Billy,

I apologize that I haven't written before, but I had to finish some
urgent projects and I haven't much time for anything else. :(  Of
course I downloaded pyPgSQL 2.1 as soon as it was announced here.  It
works very good, especially this new transaction isolation level
setting, which I asked for some time ago :))  I improved most of my
applications to use this feature and I am glad to see that everything
is OK, and even works better than before.  I wonder why people still
use other Python libraries for PostgreSQL, this one is the best! :^))

> 1.  Should pyPgSQL drop compatibility with versions of Python previous to 
> version 2.2?

It really doesn't matter for me.  My applications work with both
Python 2.1 and 2.2 (I don't use many features of Python 2.2 yet).
However, I think that it is not good for any project to keep backward
compatibility -- it always equals to more complicated code.
Even PostgreSQL evolves and some SQL commands and syntax become
obsolete, so many programmers will have to improve their programs.

The only problem arises when someone uses libraries which don't work
with newer Python releases.  For example something is wrong with
stable branch of wxPython/wxGTK library and I still haven't figured
what it could be.  The application crashes (core dumped etc.) and I
still have to use Pyhton 2.0 (!) to run it.  Hopefully I am now
switching to PyGTK and this problem will soon disappear, even if not
removed by a next wxPython version.

Generally, I vote for option 1! :)

Regards,

-- 
Adam Buraczewski <ad...@po...> * Linux registered user #165585
GCS/TW d- s-:+>+:- a- C+++(++++) UL++++$ P++ L++++ E++ W+ N++ o? K? w--
O M- V- PS+ !PE Y PGP+ t+ 5 X+ R tv- b+ DI? D G++ e+++>++++ h r+>++ y?