PostgreSQL 7.4.1 and pgdb.py

[Manuel Tejada]

Hi
My box: RedHat 9.0, Pentium III

Recently I upgraded from PostgreSQL 7.3.2 to PostgreSQL 7.4.1.
The PostgreSQL 7.3.2's rpms were installed from RehHat CDs
The PostgreSQL 7.4.1's rpms I used to upgrade were downloaded from RHEL3
subdirectory (of the mirror
ftp://ftp4.ar.postgresql.org/pub/mir.../redhat/rhel3).

The upgrade is working well, even I can connect to PostgreSQL from a PHP
script.

Before upgrading I used to connect to PostgresQL using pgdb.py (part of
PyGreSQL that comes with one of the rpms I guess). The sintaxis I was using
from interactive shell were:

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

import pgdb
dbConnect = pgdb.connect(ds n='localhost:or acle', user='manuel', password='')cursor = dbConnect.curso r()
cursor.execu te("select * from address")
while (1): .... row = cursor.fetchone ()
.... if row == None:
.... break
.... print row
....
['BAILEY','WILLI AM',None,None,N one,None,'213-293-0223',None]
['ADAMS','JACK', None,None,None, None,'415-453-7330',None]
-
-cursor.close ()
dbConnect.cl ose() -----------------------

As you can see, the connection and fechting were successful.

But now when I input the same sintaxis with the new Installation(Po stgreSQL
7.4.1), I get an error when I enter rhe four line:

----------------import pgdb
dbConnect = pgdb.connect(ds n='localhost:or acle', user='manuel', password='')cursor = dbConnect.curso r()
cursor.execu te("select * from address")

Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.2/site-packages/pgdb.py", line 189, in execute
self.executeman y(operation, (params,))
File "/usr/lib/python2.2/site-packages/pgdb.py", line 221, in executemany
desc = type[1:2]+self ._cache.getdesc r(typ[2])
File "/usr/lib/python2.2/site-packages/pgdb.py", line 149, in getdescr
self ._source.execut e(
_pg.error: ERROR: non exist the column "typprtlen"
------------------

By the way the types of columns from address table are:
lastname varchar(25)
firstname varchar(25)
street varchar(30)
city varchar(15)
state varchar(2)
zip int
phone varchar(12)
ext varchar(5)

My questions:

-Anybody knows why I can't connect to PostgreSQL using the pgdb.py module
now?
- Perhaps the sintaxis has changed?
Manuel Tejada
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Lamar Owen]

On Friday 30 January 2004 10:59 pm, Alvaro Herrera wrote:

On Fri, Jan 30, 2004 at 07:42:27PM -0800, Jeff Davis wrote:

You can probably get an updated pgdb.py somehow, or you can just use
"import pg" which has a different interface (non DBAPI-2.0 compliant)
but should work fine (since it doesn't try to access system catalogs,
it's more of a low-level PG interface for python).

Keep in mind that there's also psycopg and PyGreSql, as far as Python
interfaces go.

Since I don't necessarily keep up with what is going on in the Python client
world, would people enlighten me as to which python client would be best to
build RPMs for? I'm going to pull the python subpackage out of the main set,
but I really would like to roll a set for the python clients, unless the
maintainers of those now out of the main tarball clients have their own RPMs.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
[phone]
www.pari.edu
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postg resql.org

[Joshua D. Drake]

Since I don't necessarily keep up with what is going on in the Python client
world, would people enlighten me as to which python client would be best to
build RPMs for?
Well at CMD we only use psycopg as it is the only one we have used that
has proven to:

A. Actually be actively maintained.
B. Have a solid community behind it.
C. It is what Zope (although we don't Zope) uses.

Sincerely,

Joshua D. Drake


I'm going to pull the python subpackage out of the main set, but I really would like to roll a set for the python clients, unless the
maintainers of those now out of the main tarball clients have their own RPMs.

--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
[phone] - jd@commandpromp t.com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Gaetano Mendola]

Lamar Owen wrote:

On Friday 30 January 2004 10:59 pm, Alvaro Herrera wrote:

On Fri, Jan 30, 2004 at 07:42:27PM -0800, Jeff Davis wrote:

You can probably get an updated pgdb.py somehow, or you can just use
"import pg" which has a different interface (non DBAPI-2.0 compliant)
but should work fine (since it doesn't try to access system catalogs,
it's more of a low-level PG interface for python).

Keep in mind that there's also psycopg and PyGreSql, as far as Python
interfaces go.

Since I don't necessarily keep up with what is going on in the Python client
world, would people enlighten me as to which python client would be best to
build RPMs for? I'm going to pull the python subpackage out of the main set,
but I really would like to roll a set for the python clients, unless the
maintainers of those now out of the main tarball clients have their own RPMs.

Simply distribute the same files distributed with postgres 7.3.X, what
you did in last 7.4.1 distribution was insert a pre 7.3.2 pgdb.py
IMHO is a pity remove the pyhton subpackage just for a so little mistake.
Regards
Gaetano Mendola

[Manuel Tejada]

As a user of PostgreSQL I totally agree with Gaetano Mendola.
There is no reason to pull the python subpackage out of the main set,

----- Original Message -----
From: "Gaetano Mendola" <me*****@bigfoo t.com>
To: <pg***********@ postgresql.org>
Sent: Friday, February 06, 2004 9:24 PM
Subject: Re: [GENERAL] PostgreSQL 7.4.1 and pgdb.py

Lamar Owen wrote:

On Friday 30 January 2004 10:59 pm, Alvaro Herrera wrote:

On Fri, Jan 30, 2004 at 07:42:27PM -0800, Jeff Davis wrote:

You can probably get an updated pgdb.py somehow, or you can just use
"import pg" which has a different interface (non DBAPI-2.0 compliant)
but should work fine (since it doesn't try to access system catalogs,
it's more of a low-level PG interface for python).

Keep in mind that there's also psycopg and PyGreSql, as far as Python
interfaces go.

Since I don't necessarily keep up with what is going on in the Python client world, would people enlighten me as to which python client would be best to build RPMs for? I'm going to pull the python subpackage out of the main set, but I really would like to roll a set for the python clients, unless the
maintainers of those now out of the main tarball clients have their own

RPMs.

Simply distribute the same files distributed with postgres 7.3.X, what
you did in last 7.4.1 distribution was insert a pre 7.3.2 pgdb.py
IMHO is a pity remove the pyhton subpackage just for a so little mistake.
Regards
Gaetano Mendola

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postg resql.org

[Kris Jurka]

On Sun, 8 Feb 2004, Manuel Tejada wrote:

Lamar Owen wrote:

Since I don't necessarily keep up with what is going on in the Python client world, would people enlighten me as to which python client would be best to build RPMs for? I'm going to pull the python subpackage out of the main set, but I really would like to roll a set for the python clients, unless the
maintainers of those now out of the main tarball clients have their own

RPMs.

As a user of PostgreSQL I totally agree with Gaetano Mendola.
There is no reason to pull the python subpackage out of the main set,

The decision to remove all interfaces from the main CVS tree was made in
part to remove the responsibility of the core developers to maintain the
build systems for various components and try to make sure that bugs and
new backend functionality were addressed. While this allows core
developers to focus solely on the backend it puts a lot of pressure on the
packagers to track the various components they are now distributing.
This is not the first packaging problem and it won't be the last if we
rely on a very busy package maintainer to track each independent project.
The only people who really know which version needs to go into an package
are the projects' maintainers.

Asking the interface projects to build and distribute their own packages
is not going to work because they are not likely to have all of the
requirements the existing packagers already have: expertise with the
packaging system, access to machines to build this on a variety of
platforms, and contacts with the upstream package distributors.

Perhaps a system where each project maintainer could register the correct
version of their package to go with each server version. This way in
addition to the hackers email that goes out saying "we're planning on
making the 7.X.X release on Monday" this would also go out to the project
maintainers who would then produce a new version if necessary and register
it on a website somewhere. Then when a packager is ready to produce a
package he can check the website and immediately find for all packages the
correct version of the package to distribute.

Lamar, Oliver, interface maintainers, and others would that be useful?

Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend