You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(18) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(11) |
Feb
(7) |
Mar
(7) |
Apr
(7) |
May
(17) |
Jun
(33) |
Jul
(19) |
Aug
(3) |
Sep
(19) |
Oct
(18) |
Nov
(27) |
Dec
(13) |
2003 |
Jan
(12) |
Feb
(8) |
Mar
(11) |
Apr
(42) |
May
(19) |
Jun
(49) |
Jul
(23) |
Aug
(12) |
Sep
(2) |
Oct
(8) |
Nov
(8) |
Dec
(13) |
2004 |
Jan
(13) |
Feb
(2) |
Mar
(7) |
Apr
(7) |
May
(6) |
Jun
(13) |
Jul
(4) |
Aug
(12) |
Sep
(6) |
Oct
(6) |
Nov
(50) |
Dec
(10) |
2005 |
Jan
(20) |
Feb
(20) |
Mar
(2) |
Apr
(10) |
May
(12) |
Jun
(7) |
Jul
|
Aug
(4) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2006 |
Jan
(2) |
Feb
(2) |
Mar
(5) |
Apr
(6) |
May
(3) |
Jun
(17) |
Jul
(2) |
Aug
(8) |
Sep
(1) |
Oct
(5) |
Nov
(3) |
Dec
(2) |
2007 |
Jan
(2) |
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2008 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2009 |
Jan
(2) |
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Milton i. <min...@gm...> - 2005-06-02 18:01:49
|
2005/6/2, Karsten Hilbert <Kar...@gm...>: > On Thu, Jun 02, 2005 at 12:39:09PM -0400, Milton inostroza wrote: > > > > hello: I need insert file's into bytea column but I have not managed > > to find information like doing it. >=20 > http://savannah.gnu.org/cgi-bin/viewcvs/gnumed/gnumed/gnumed/client/busin= ess/gmMedDoc.py?rev=3D1.2&content-type=3Dtext/vnd.viewcvs-markup >=20 > Look at >=20 > def update_data_from_file() i don't find this method in the addres, me you can send a concrete example of like doing it, if it is that it is not much annoyance >=20 > Karsten > -- > GPG key ID E4071346 @ wwwkeys.pgp.net > E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22= 005 > _______________________________________________ > Pypgsql-users mailing list > Pyp...@li... > https://lists.sourceforge.net/lists/listinfo/pypgsql-users >=20 --=20 Milton Inostroza Aguilera Secretario Academico Centro de Alumnos Encargado de Auspicios y Patrocinios - 6to. Encuentro Nacional de Linux Desarrollador de RemuneX (sistema de remuneraciones amparado bajo GPL) |
From: Karsten H. <Kar...@gm...> - 2005-06-02 17:40:23
|
On Thu, Jun 02, 2005 at 12:39:09PM -0400, Milton inostroza wrote: > > hello: I need insert file's into bytea column but I have not managed > to find information like doing it. http://savannah.gnu.org/cgi-bin/viewcvs/gnumed/gnumed/gnumed/client/business/gmMedDoc.py?rev=1.2&content-type=text/vnd.viewcvs-markup Look at def update_data_from_file() Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 |
From: Milton i. <min...@gm...> - 2005-06-02 16:45:59
|
hello: I need insert file's into bytea column but I have not managed to find information like doing it. =20 it uses field in the beginning type oid but lo_import and lo_export, it is possible to be only executed with permission of super user and that does not serve to me =20 the description of the table is the following one =20 CREATE TABLE public.prueba ( codigo_fichero serial NOT NULL, archivo bytea ) WITHOUT OIDS; =20 Help me, please, saludos desde Chile -- Milton Inostroza Aguilera Desarrollador de RemuneX (sistema de remuneraciones amparado bajo GPL) |
From: Andrew M. <an...@ob...> - 2005-05-23 23:55:44
|
>I believe that pyPgSQL shouldn't (have to) fuzz around with >adjusting the date/time data in the first place. And if that's what it did, I would be happy. >> Operating on timezones is like waltzing through a minefield - I'm not >> sure what to suggest to fix this, but I think the PG_TIMESTAMP type >> ("without time zone") should make the round-trip to postgres and back >> unmollested by default. >That is quite true. If one retrieves a "timestamp" field >there is no timezone information to be had as there is none. > >Maybe I am missing the real issue ? I think so. mx.DateTime objects are just a date and time. While they have an idea of the current timezone offset, they're neither UTC nor localtime. They provide two convenience methods, localtime() and gmtime() which add and subtract the gmtoffset() respectively. The user of the type can choose whether the source DateTime object represents localtime or gmtime. Now, the PG_TIMESTAMPTZ string includes a timezone offset in it's value, and Parser.DateTimeFromString correctly honours this, so it's a mistake to then apply the system timezone adjustment to the value. In the PG_TIMESTAMP case, pgPgSQL cannot know whether the value returned from the user's database is localtime() or gmtime() *BUT* an insert/update and subsequent fetch should be idempotent - it should return the same value inserted - which doesn't happen if you adjust by gmtoffset(). The third issue is, I think, that useUTCtimeValue isn't applied consistently - the handleArray() method doesn't honour it. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ |
From: Karsten H. <Kar...@gm...> - 2005-05-23 20:20:24
|
On Mon, May 23, 2005 at 04:13:25PM +1000, Andrew McNamara wrote: > > Bill recently checked in this change: > > date: 2005/05/16 03:37:56; author: ballie01; state: Exp; lines: +23 -4 > 15MAY2005 bga > A change to the datetime parsing changed the default datetime object > from localtime to UTC. This update returns the default to localtime > and adds a new variable, 'useUTCtimeValue' to control the default > value of a datetime object. Setting it to 1 will cause the datetime > object to reference the UTC time, 0 will cause the datetime object to > reference the client's local time zone. I do believe the application should have to know what time zone it requested a date time object at. > The results are not idempotent - a DateTime saved to the database comes > back adjusted by the current timezone offset. Depending on the setting > of useUTCtimeValue, either PG_TIMESTAMP or PG_TIMESTAMPTZ is wrong. If > an application used only one of these types, useUTCtimeValue could be > set appropriate, but if the application uses both, it's in trouble. That application is in trouble anyways. There cannot be any clarity when ambigous programming is used. I believe that pyPgSQL shouldn't (have to) fuzz around with adjusting the date/time data in the first place. Any responsible application will issue "set timezone ...;" appropriately for every session. Or else (in case it needs datetimes adjusted to many different time zones within one and the same session) it will use "select ... at time zone ...;". Everything else is broken (unless there are errors in my thinking) and pyPgSQL should not be blamed for it. > Operating on timezones is like waltzing through a minefield - I'm not > sure what to suggest to fix this, but I think the PG_TIMESTAMP type > ("without time zone") should make the round-trip to postgres and back > unmollested by default. That is quite true. If one retrieves a "timestamp" field there is no timezone information to be had as there is none. Maybe I am missing the real issue ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 |
From: Andrew M. <an...@ob...> - 2005-05-23 06:13:30
|
Bill recently checked in this change: date: 2005/05/16 03:37:56; author: ballie01; state: Exp; lines: +23 -4 15MAY2005 bga A change to the datetime parsing changed the default datetime object from localtime to UTC. This update returns the default to localtime and adds a new variable, 'useUTCtimeValue' to control the default value of a datetime object. Setting it to 1 will cause the datetime object to reference the UTC time, 0 will cause the datetime object to reference the client's local time zone. The results are not idempotent - a DateTime saved to the database comes back adjusted by the current timezone offset. Depending on the setting of useUTCtimeValue, either PG_TIMESTAMP or PG_TIMESTAMPTZ is wrong. If an application used only one of these types, useUTCtimeValue could be set appropriate, but if the application uses both, it's in trouble. I also note that there are other places where DateTimeFromString is used where useUTCtimeValue is not honoured (handleArray). Operating on timezones is like waltzing through a minefield - I'm not sure what to suggest to fix this, but I think the PG_TIMESTAMP type ("without time zone") should make the round-trip to postgres and back unmollested by default. Welcome to psql 7.4.7, the PostgreSQL interactive terminal. test=# create table x (y timestamp without time zone, z timestamp with time zone); CREATE TABLE test=# insert into x values (now(), now()); INSERT 10353883 1 test=# select * from x; y | z ----------------------------+------------------------------- 2005-05-23 16:10:51.451112 | 2005-05-23 16:10:51.451112+10 (1 row) 1$ python2.4 Python 2.4.1 (#2, May 5 2005, 11:32:06) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 >>> from pyPgSQL import PgSQL >>> db=PgSQL.connect(database="test") >>> c=db.cursor() >>> c.execute('select * from x') >>> c.fetchone() [<DateTime object for '2005-05-24 02:10:51.45' at b7e7f838>, <DateTime object for '2005-05-23 16:10:51.45' at b7e873d8>] -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ |
From: Andrew M. <an...@ob...> - 2005-05-23 05:55:11
|
>The issue has been fixed in CVS HEAD code base. That fixed my problem, but I think you also need to handle PG_TIMETZ. This sort of thing should have been caught by the unittests... which, btw, appear to be broken with Python 2.4: 1$ (cd test && python2.3 PgSQLTestCases.py) .................................................................. ---------------------------------------------------------------------- Ran 66 tests in 2.019s OK 1$ (cd test && python2.4 PgSQLTestCases.py) ...............F.................................................. ====================================================================== FAIL: CheckPgInt2 (__main__.PgSQLTestModuleInterface) ---------------------------------------------------------------------- Traceback (most recent call last): File "PgSQLTestCases.py", line 219, in CheckPgInt2 self.failUnless(a == 181.0, 'PgInt2 comparison to Float failed.') AssertionError: PgInt2 comparison to Float failed. ---------------------------------------------------------------------- Ran 66 tests in 0.958s FAILED (failures=1) -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ |
From: Billy G. A. <bil...@de...> - 2005-05-21 01:32:55
|
On Fri, 2005-05-20 at 11:51 +1000, Andrew McNamara wrote: > In the current CVS HEAD, columns of type "time" are being returned as > DateTime objects, rather than Time objects (DateTimeDelta): > > Welcome to psql 7.4.7, the PostgreSQL interactive terminal. > > test=# create table x ( y time, z time with time zone); > CREATE TABLE > test=# insert into x values (now(), now()); > INSERT 10352072 1 > test=# select * from x; > y | z > -----------------+-------------------- > 11:46:25.602349 | 11:46:25.602349+10 > > Python 2.4.1 (#2, May 5 2005, 11:32:06) > [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 > >>> from pyPgSQL import PgSQL > >>> db=PgSQL.connect(database="test") > >>> c=db.cursor() > >>> c.execute('select * from x') > >>> c.fetchone() > [<DateTime object for '2005-05-20 21:46:25.60' at b7e7b950>, <DateTime object for '2005-05-20 11:46:25.60' at b7e88db0>] > The issue has been fixed in CVS HEAD code base. |
From: Andrew M. <an...@ob...> - 2005-05-20 01:51:44
|
In the current CVS HEAD, columns of type "time" are being returned as DateTime objects, rather than Time objects (DateTimeDelta): Welcome to psql 7.4.7, the PostgreSQL interactive terminal. test=# create table x ( y time, z time with time zone); CREATE TABLE test=# insert into x values (now(), now()); INSERT 10352072 1 test=# select * from x; y | z -----------------+-------------------- 11:46:25.602349 | 11:46:25.602349+10 Python 2.4.1 (#2, May 5 2005, 11:32:06) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 >>> from pyPgSQL import PgSQL >>> db=PgSQL.connect(database="test") >>> c=db.cursor() >>> c.execute('select * from x') >>> c.fetchone() [<DateTime object for '2005-05-20 21:46:25.60' at b7e7b950>, <DateTime object for '2005-05-20 11:46:25.60' at b7e88db0>] -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ |
From: Timothy S. <ti...@op...> - 2005-05-17 21:49:26
|
Karsten Hilbert wrote: >On Tue, May 17, 2005 at 09:01:14AM +1000, Timothy Smith wrote: > > >>is it possible to mke a progress bar for queries? say i have a query >>that will take 20 seconds, i'd like to give some feed back to users on >>how long this will take. >> >> >It is sure possible but it is not very useful because > >- you will need the number of rows in the result >- which could be gotten by "select count(*) from ... where ..." >- which, however, takes pretty much the same time as the query itself >- which is in part due to PostgreSQL's MVCC nature >- which cannot be sped up by using an index >- because current tuple visibility is not stored in the index >- and doing so would create overhead for insert/update > >Karsten > > it's a very useful feature, however as you pointed out it'd be almost impossible to implement |
From: Karsten H. <Kar...@gm...> - 2005-05-17 19:20:22
|
On Tue, May 17, 2005 at 09:01:14AM +1000, Timothy Smith wrote: > > is it possible to mke a progress bar for queries? say i have a query > that will take 20 seconds, i'd like to give some feed back to users on > how long this will take. It is sure possible but it is not very useful because - you will need the number of rows in the result - which could be gotten by "select count(*) from ... where ..." - which, however, takes pretty much the same time as the query itself - which is in part due to PostgreSQL's MVCC nature - which cannot be sped up by using an index - because current tuple visibility is not stored in the index - and doing so would create overhead for insert/update Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 |
From: Timothy S. <ti...@op...> - 2005-05-16 23:03:04
|
is it possible to mke a progress bar for queries? say i have a query that will take 20 seconds, i'd like to give some feed back to users on how long this will take. |
From: Karsten H. <Kar...@gm...> - 2005-05-12 16:00:19
|
> sql =""" > INSERT INTO trabajador > VALUES("""+ ",".join(["'%s'" %(n1) for n1 in trabajador])+")" > self.cursor.execute(sql) Don't do that. Do sql = "... where ... = %s and ... = %s and ..." self.cursor.execute(sql, trabadajor) Otherwise people can run SQL injection attacks unless you are *really* careful. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 |
From: Milton i. <min...@gm...> - 2005-05-12 15:33:29
|
El 12/05/05, Milton inostroza<min...@gm...> escribi=F3: > db =3D PgSQL.connect(...) > db.autocommit =3D True Debes tener cuidado con esta linea db.autocommit=3DTrue, ya que si quieres insertar por ejemplo en 3 tablas y est=E1s est=E1n relacionadas te producir=E1n un gran dolor de cabeza...observa: =20 table direccion, table trabajador, el trabajador tiene una direccion y direccion puede tener a uno o muchos trabajadores (esta es la relacion), entonces en codigo quedar=EDa de la siguiente manera =20 try: insertar en direccion insertar en trabajador (utilizando la pk de direccion como fk en trabajador) except: sys.exc_info()[1] (imprime el tipo de exception) =20 ahora, pregunta que pasa al utilizar db.autocommit=3DTrue....imaginate que en direccion se inserte todo bien y en trabajador exista un problema (imaginate que existe un campo int y el usuario lo ingresa como cadena) entonces trabajador no se inserta y te manda la exception (ahi todo bien)....PERO esto es erroneo ya que ingresaste una direccion pero no a un trabajador ahora con autocommit el rollback no funciona, entonces te quedaste con una direccion que no es de nadie y eso es un ERROR GRAVE en un sistema de verdad. =20 En mi sistema elimine el autocommit=3DTrue y trabajo de esta forma, me da menos dolores de cabeza y la curva de verificaciones de datos decrece un monton (cantidad de if para verificar que los campos sean correctos). =20 bueno ahi va el codigo =20 db =3D PgSQL.connect(...) cursor=3Ddb.cursor() =20 try: sql =3D""" INSERT INTO direccion (nombre_comuna,nombre_calle_direccion, numero_direccion,block_direccion, departamento_direccion ) VALUES ('%s','%s','%s','%s','%s') """%( self.comboboxentryComuna.child.get_text().upper(), self.entryCalle.get_text().upper(), self.entryNumero.get_text(), self.entryBlock.get_text().upper(), self.entryDepartamento.get_text() ) cursor.execute(sql) =20 sql =3D""" INSERT INTO trabajador VALUES("""+ ",".join(["'%s'" %(n1) for n1 in trabajador])= +")" self.cursor.execute(sql) =20 db.commit() except: print sys.exc_info()[1] db.rollback() =20 db.close() =20 si te das cuenta realizo un commit() cuando todas las inserciones se realizan de forma satisfactoria, en el except pongo imprimir el error y un rollback para eliminar cualquier transaccion que se haya realizado y que no me sirva, ejemplo: que se haya insertado bien direccion y mal trabajador, ESO no me sirve entonces aplico un rollback(). =20 my language is Spanish-Chile, I did not write in ingles because it was occupied making a task. I hope that my aid serves to you. =20 -- Milton Inostroza Aguilera Secretario Academico Centro de Alumnos Encargado de Auspicios y Patrocinios - 6to. Encuentro Nacional de Linux Desarrollador de RemuneX (sistema de remuneraciones amparado bajo GPL) |
From: Karsten H. <Kar...@gm...> - 2005-04-29 15:40:27
|
> >pyPgSQL version 3 > >will have a way to register user defined types so that pyPgSQL will do > >the right thing with it. This is the first mention of pyPgSQL v3 I have seen - or in fact any other *mentioning* of ongoing development. I think pyPgSQL isn't half bad technically but does need an odd post or another on the list every now and then. Say, one or two a month would do. It would immediately stop making users feel like they are dealing with an opaque, immovable entity. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 |
From: Michael H. <Michael@Hipp.com> - 2005-04-29 14:17:24
|
Billy G. Allie wrote: > On Mon, 2005-04-25 at 13:42 -0500, Michael Hipp wrote: > >>I'm really hoping someone can tell me I'm doing something wrong ... >> >>I have a table that has a complex (user defined) type like this: >> >>CREATE TYPE addr_phone AS ( >> addr1 character varying(40), >> addr2 character varying(40), >> city character varying(40), >> state character(2), >> zip character(5), >> phone character(12)) [snip] > pyPgSQL doesn't know about user created types. You would need to create > a python type that represents yoour created type and then instantiate an > object of that type passing it the string returned by the query. (HINT: > if your python type has a _quote() function, then pyPgSQL will use it to > quote the value when it is used in a query). Right now, integrating > that type into pyPgSQL is not easy, but can be done. pyPgSQL version 3 > will have a way to register user defined types so that pyPgSQL will do > the right thing with it. Thank you. If I comprehend the explanation, the bottom line is that I must parse that raw string in order to get the data out of it. Creating a matching python type hides those machinations from the rest of the program but the gory work must still be done. Correct? Michael |
From: Michael H. <Michael@Hipp.com> - 2005-04-25 18:41:10
|
I'm really hoping someone can tell me I'm doing something wrong ... I have a table that has a complex (user defined) type like this: CREATE TYPE addr_phone AS ( addr1 character varying(40), addr2 character varying(40), city character varying(40), state character(2), zip character(5), phone character(12)) Inserting and updating the table that contains such a type is no problem, but when I do a select, I get the complex "column" returned as one big string like this: '(a,b,c,"d ","e ","f ")' Note that it looks superficially like a tuple but it isn't. I thought to be smart and use 'exec' to convert that to a tuple but the first three items aren't quoted. I would have thought such a complex type would be returned as a list or a PgArray? Anything to be done about this or am I missing something? Thanks, Michael |
From: Andrew M. <an...@ob...> - 2005-04-20 03:51:20
|
>> If I attempt to: >> cursor.execute('create database blah...') >> I get the following error: >> libpq OperationalError: ERROR: CREATE DATABASE cannot run inside a >> transaction block >> >> How can I accomplish my objective? > >Here's one way to do it, though kludgey: > cursor.execute('commit') # note that this closes our transaction, so >that the following works: > cursor.execute('create database blah') The method I use is: db = PgSQL.connect(...) db.autocommit = True curs = db.cursor() curs.execute('....') db.close() -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ |
From: J. M. C. <jm...@do...> - 2005-04-18 23:43:26
|
Here's one way to do it, though kludgey: cursor.execute('commit') # note that this closes our transaction, so that the following works: cursor.execute('create database blah') J. Michael Caine wrote: > If I attempt to: > cursor.execute('create database blah...') > I get the following error: > libpq OperationalError: ERROR: CREATE DATABASE cannot run inside a > transaction block > > How can I accomplish my objective? > |
From: J. M. C. <jm...@do...> - 2005-04-18 23:35:18
|
If I attempt to: cursor.execute('create database blah...') I get the following error: libpq OperationalError: ERROR: CREATE DATABASE cannot run inside a transaction block How can I accomplish my objective? |
From: J. M. C. <jm...@do...> - 2005-04-18 23:12:01
|
If I attempt to: cursor.execute('create database blah...') I get the following error: libpq OperationalError: ERROR: CREATE DATABASE cannot run inside a transaction block How can I accomplish my objective? |
From: Gerhard H. <gh...@gh...> - 2005-04-13 17:13:27
|
On Wed, Apr 13, 2005 at 11:48:28AM +0000, Antonio Prado wrote: > I am with the following problem: >=20 > from pyPgSQL.PgSQL import connect >=20 > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "/usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py", line 391, in ? > from libpq import * > File "/usr/lib/python2.3/site-packages/pyPgSQL/libpq/__init__.py",=20 > line 23, in ? > from libpq import * > ImportError:=20 > /usr/lib/python2.3/site-packages/pyPgSQL/libpq/libpqmodule.so: undefined= =20 > symbol: PyUnicodeUCS4_EncodeDecimal >=20 >=20 > I have installed: > pyPgSQL-2.4-1 > postgresql-7.4.5-71534cl > python-2.3.4-71533cl > libpq3-7.4.5-71534cl > Conectiva Linux 10. The pyPgSQL RPM you installed is not binary compatible with the Python RPM you installed, due to different Unicode settings while Python was compiled. The Python you installed was built with --enable-unicode=3Ducs2 and the One pyPgSQL was built with was built with --enable-unicode=3Ducs4 or some similar weirdness. If you have access to the pyPgSQL source RPM, a rpm --rebuild pyPgSQL-2.4-1.src.rpm should help to create a usable pyPgSQL package. Otherwise I'd recommend you insteall pyPgSQL directly from sources. HTH, -- Gerhard |
From: Antonio P. <su...@an...> - 2005-04-13 14:38:06
|
I am with the following problem: from pyPgSQL.PgSQL import connect Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py", line 391, in ? from libpq import * File "/usr/lib/python2.3/site-packages/pyPgSQL/libpq/__init__.py", line 23, in ? from libpq import * ImportError: /usr/lib/python2.3/site-packages/pyPgSQL/libpq/libpqmodule.so: undefined symbol: PyUnicodeUCS4_EncodeDecimal I have installed: pyPgSQL-2.4-1 postgresql-7.4.5-71534cl python-2.3.4-71533cl libpq3-7.4.5-71534cl Conectiva Linux 10. Antonio. |
From: Antonio P. <su...@an...> - 2005-04-12 14:33:26
|
I am with the following problem: from pyPgSQL.PgSQL import connect Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py", line 391, in ? from libpq import * File "/usr/lib/python2.3/site-packages/pyPgSQL/libpq/__init__.py", line 23, in ? from libpq import * ImportError: /usr/lib/python2.3/site-packages/pyPgSQL/libpq/libpqmodule.so: undefined symbol: PyUnicodeUCS4_EncodeDecimal I have installed: pyPgSQL-2.4-1 postgresql-7.4.5-71534cl python-2.3.4-71533cl libpq3-7.4.5-71534cl Conectiva Linux 10. Antonio. |
From: <den...@ri...> - 2005-03-23 14:01:24
|
I installed pyPgSQL on a QNX 6.2.1 machine. I already installed Python 2.2.1 as PostgreSQL 4.1.10, both of them run normally. The installation of pyPgSQL ran normally, but when I try to start the pyPgSQL example I have the following message : bash-2.05a# python test/PgSQLTestCases.py Traceback (most recent call last): File "test/PgSQLTestCases.py", line 89, in ? from pyPgSQL import PgSQL File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 391, in ? from libpq import * File "/usr/lib/python2.2/site-packages/pyPgSQL/libpq/__init__.py", line 23, in ? from libpq import * ImportError: Library cannot be found bash-2.05a# It seems that pyPgSQL needs the library libpq.so, but the only one I have is in the lib directory of PostgreSQL '/usr/local/pgsql/lib'. I tried to put libpq.so in the python lib-dynload directory, but the result is the same. Do you have any idea on what I could do ? |