Re: [GENERAL] PostgreSQL 7.4.1 and pgdb.py
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
Re: [GENERAL] PostgreSQL 7.4.1 and pgdb.py
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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Re: [GENERAL] PostgreSQL 7.4.1 and pgdb.py
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] PostgreSQL 7.4.1 and pgdb.py
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" <[EMAIL PROTECTED]>
Newsgroups: comp.databases.postgresql.general
Cc: "Manuel Tejada" <[EMAIL PROTECTED]>
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 "", 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-bugs/2002-12/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
Re: [GENERAL] PostgreSQL 7.4.1 and pgdb.py
Tom Lane wrote: "Manuel Tejada" <[EMAIL PROTECTED]> 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-bugs/2002-12/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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] 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 "", 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-bugs/2002-12/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
