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(dsn='localhost:oracle', user='manuel',
password='')cursor = dbConnect.cursor() cursor.execute("select * from address") while (1):
.... row = cursor.fetchone()
.... if row == None:
.... break
.... print row
....
['BAILEY','WILLIAM',None,None,None,None,'213-293-0223',None]
['ADAMS','JACK',None,None,None,None,'415-453-7330',None]
-
-cursor.close() dbConnect.close()
-----------------------
As you can see, the connection and fechting were successful.
But now when I input the same sintaxis with the new Installation(PostgreSQL
7.4.1), I get an error when I enter rhe four line:
----------------import pgdb dbConnect = pgdb.connect(dsn='localhost:oracle', user='manuel',
password='')cursor = dbConnect.cursor() cursor.execute("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.executemany(operation, (params,))
File "/usr/lib/python2.2/site-packages/pgdb.py", line 221, in executemany
desc = type[1:2]+self ._cache.getdescr(typ[2])
File "/usr/lib/python2.2/site-packages/pgdb.py", line 149, in getdescr
self ._source.execute(
_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 14 4067
> >>>cursor.execute("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.executemany(operation, (params,)) File "/usr/lib/python2.2/site-packages/pgdb.py", line 221, in executemany desc = type[1:2]+self ._cache.getdescr(typ[2]) File "/usr/lib/python2.2/site-packages/pgdb.py", line 149, in getdescr self ._source.execute( _pg.error: ERROR: non exist the column "typprtlen"
That's a column in a system catalog table (starts with "pg_"). The
pgdb.py must be trying to access an out of date version of the system
catalog.
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).
In short, the problem exists in pgdb.py, which is trying to access
information in an out-of-date way.
Regards,
Jeff Davis
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)
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.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Pido que me den el Nobel por razones humanitarias" (Nicanor Parra)
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)
> Keep in mind that there's also psycopg and PyGreSql, as far as Python interfaces go.
pg.py and pgdb.py are both part of PyGreSQL. pg.py is the more low-level
interface, closer to a wrapper of libpq (but with lots of helper
functions to make it natural to use in python), and pgdb.py is
PyGreSQL's DBAPI-2.0-compliant interface, which is compatible with other
interfaces in python (so you could swap out another DB for PostgreSQL
without code changes, ideally).
pgdb.py, in compliance with the DBAPI-2.0 spec, does things like match
data types up by using the system catalogs (so you don't have to convert
from text) and has even more features to make it even more natural to
use with python. However, with each version change, pgdb.py needs to be
updated to match the current version of the postgres catalogs, which is
the problem the poster ran into. I think it's supposed to be similar to
JDBC in some respects.
I usually use pg.py, so I might have some details wrong about pgdb.py.
Regards,
Jeff Davis
---------------------------(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
"Manuel Tejada" <ma*****@terra.com.pe> writes: But now when I input the same sintaxis with the new Installation(PostgreSQL 7.4.1), I get an error when I enter rhe four line:
_pg.error: ERROR: non exist the column "typprtlen"
I believe this indicates you're using an old version of the PyGreSQL
module. typprtlen disappeared from the pg_type system catalog several
releases back. There is updated PyGreSQL code out there, but I'm not
very sure where --- have you looked at gborg.postgresql.org?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)
Old version of the PyGreSQL?
Remember I said that I made un apgrade to PostgreSQL version 7.4.1.
One of rpms I used to upgrade is the postgresql-python-7.4.1-1PGDG.i386.rpm.
I suppose that this come with the last version of PyGreSQL.
The README file in /usr/share/doc/postgresql-python-7.4.1 tells that the
module PyGreSQL is version 3.4. This version is the last according to ftp://ftp.druid.net/pub/distrib/
When I use the module C or the module pg.py of PyGreSQL to connect with
PostgreSQL, they work fine.
But I would like to use the pgdb.py too
----- Original Message -----
From: "Tom Lane" <tg*@sss.pgh.pa.us>
To: "Manuel Tejada" <ma*****@terra.com.pe>
Cc: <pg***********@postgresql.org>
Sent: Friday, January 30, 2004 11:41 PM
Subject: Re: [GENERAL] PostgreSQL 7.4.1 and pgdb.py "Manuel Tejada" <ma*****@terra.com.pe> writes: But now when I input the same sintaxis with the new
Installation(PostgreSQL 7.4.1), I get an error when I enter rhe four line:
_pg.error: ERROR: non exist the column "typprtlen"
I believe this indicates you're using an old version of the PyGreSQL module. typprtlen disappeared from the pg_type system catalog several releases back. There is updated PyGreSQL code out there, but I'm not very sure where --- have you looked at gborg.postgresql.org?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives? http://archives.postgresql.org
Manuel Tejada wrote: import pgdb dbConnect = pgdb.connect(dsn='localhost:oracle', user='manuel', password='') cursor = dbConnect.cursor() cursor.execute("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.executemany(operation, (params,)) File "/usr/lib/python2.2/site-packages/pgdb.py", line 221, in executemany desc = type[1:2]+self ._cache.getdescr(typ[2]) File "/usr/lib/python2.2/site-packages/pgdb.py", line 149, in getdescr self ._source.execute( _pg.error: ERROR: non exist the column "typprtlen" ------------------
This is a really old problem already solved on 7.3 see this my post: http://archives.postgresql.org/pgsql...2/msg00082.php
I'm checking that my 7.4.1 installation is affected by the same
problem. I don't understand how this could happen that a modification
made on a 7.3 was not ported to 7.4
For the moment what you can do is substitute this select:
"SELECT typname, typprtlen, typlen "
"FROM pg_type WHERE oid = %s" % oid
inside the file pgdb.py with this one:
"SELECT typname, 4, typlen "
"FROM pg_type WHERE oid = %s" % oid
just to not break all file.
I'm not able to look at CVS to see where the modification was lost.
Regards
Gaetano Mendola
Tom Lane wrote: "Manuel Tejada" <ma*****@terra.com.pe> writes:
But now when I input the same sintaxis with the new Installation(PostgreSQL 7.4.1), I get an error when I enter rhe four line:
_pg.error: ERROR: non exist the column "typprtlen"
I believe this indicates you're using an old version of the PyGreSQL module. typprtlen disappeared from the pg_type system catalog several releases back. There is updated PyGreSQL code out there, but I'm not very sure where --- have you looked at gborg.postgresql.org?
Unfortunately the pgdb.py is wrong and is shipped with
postgresql-python-7.4.1-1PGDG.i386.rpm
this problem was solved already on 7.3
look this: http://archives.postgresql.org/pgsql...2/msg00082.php
something did wrong during the SRPM file building for the 7.4.1
Is a good idea look how this happen.
Regards
Gaetano Mendola
Thank you very much Gaetano
I edited the pgdb.py file setting "4" instead of "typprtlen".
Now I am able to connect to PostgreSQL using pgdb.py.
Just for curiosity, Can I set to -1 too as Gerhard Haring told to you?
----- Original Message -----
From: "Gaetano Mendola" <me*****@bigfoot.com>
Newsgroups: comp.databases.postgresql.general
Cc: "Manuel Tejada" <ma*****@terra.com.pe>
Sent: Sunday, February 01, 2004 4:48 PM
Subject: Re: PostgreSQL 7.4.1 and pgdb.py Manuel Tejada wrote:>import pgdb >dbConnect = pgdb.connect(dsn='localhost:oracle', user='manuel',
password='')
>cursor = dbConnect.cursor() >cursor.execute("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.executemany(operation, (params,)) File "/usr/lib/python2.2/site-packages/pgdb.py", line 221, in
executemany desc = type[1:2]+self ._cache.getdescr(typ[2]) File "/usr/lib/python2.2/site-packages/pgdb.py", line 149, in
getdescr self ._source.execute( _pg.error: ERROR: non exist the column "typprtlen" ------------------
This is a really old problem already solved on 7.3 see this my post:
http://archives.postgresql.org/pgsql...2/msg00082.php
I'm checking that my 7.4.1 installation is affected by the same problem. I don't understand how this could happen that a modification made on a 7.3 was not ported to 7.4
For the moment what you can do is substitute this select:
"SELECT typname, typprtlen, typlen " "FROM pg_type WHERE oid = %s" % oid
inside the file pgdb.py with this one:
"SELECT typname, 4, typlen " "FROM pg_type WHERE oid = %s" % oid
just to not break all file.
I'm not able to look at CVS to see where the modification was lost.
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
Manuel Tejada wrote: Thank you very much Gaetano
I edited the pgdb.py file setting "4" instead of "typprtlen". Now I am able to connect to PostgreSQL using pgdb.py.
Just for curiosity, Can I set to -1 too as Gerhard Haring told to you?
I think yes, I really didn't dig on it to see the usage of that
value.
Regards
Gaetano Mendola
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
(828)862-5554 www.pari.edu
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org 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.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
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
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*****@bigfoot.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*******@postgresql.org
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Chuck Amadi |
last post by:
Hi all
Anyone know a good Pygresql Tutorial for Interfacing between Python &
Postgresql .
Cheers
Chuck
|
by: Lance Hoffmeyer |
last post by:
Hello,
I am trying to learn some basics of python. One of the things
I want to do is write a script to access a postgresql database
DB as user USER with password PW and
SELECT first_name,...
|
by: Mage |
last post by:
Hello,
I started to write my PostgreSQL layer. I tried pyPgSQL and PyGreSQL. I
made a *very minimal* performance test and comparsion with the same
thing in php. Table "movie" has 129 record and...
|
by: Ram |
last post by:
Dear All
I am very new to python . i would appreciate any help from you all on
this problem which i am facing.
I am trying to connect to postgres from python.for this i am using
something like...
|
by: James Saker |
last post by:
Just curious if anyone's aware of a good recipe for setting up SSL access to
postgresql for pgdb (or another appropriate db-sig 2 compliant module). Or
any good recommendations/considerations e.g....
|
by: artistlikeu |
last post by:
i have connected database with python program.... this program is simulation using Simpy. i call all simulation data from Postgresql using pgdb.
is it possible that i can send some of results by...
|
by: dpholmes |
last post by:
hi everyone, i'm very new to python and to this forum. i'm actually
just trying to work through the tutorial on webpy.org. so far, so
good, but as i tried to incorporate a postgresql database...
|
by: SteveD |
last post by:
Hi guys,
http://luaforge.net/frs/?group_id=327
pgdb.zip is an addition to scite-debug, which adds source debugging to
the popular SciTE programmer's editor. gdbpy.zip is a standalone
version...
|
by: Johannes Bauer |
last post by:
Hello group,
I've run into a small problem with pgdb which is actually not PostgreSQL
specific - I just do not understand the Python syntax at one point.
I'm trying to initialize a connection...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |