pypgsql-users — Discussion list for the pyPgSQL user community.

Re: [Pypgsql-users] Help: Installation problems on RedHat 6.2 / 7.2

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

On Sun, Nov 04, 2001 at 04:33:40PM +0400, dubal wrote:
> We tried this (pypgsql). We did not have any of the above problems.
> However, we could not read any date columns from db.

Are You sure that You have properly installed and working
egenic-mx-base package?  Could You send here some error messages?
What does "we could not read" mean?  Please, be more concrete if You
want someone to help You... :)

> Also while installing, python2 setup.py build aborts with gcc complaining: 
> gcc: unrecognized option `-R/usr/lib/pgsql'

I think this is problem with a broken Python installation.  What is
the version of pyPgSQL and Python You are working with?  Have You
compiled everyting yourself or used ready .rpm packages?

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] Solved: Installation problems on RedHat 6.2 / 7.2

[dubal <du...@kh...>]

Many thanks for your very prompt response.
1. As for the installation problem, you have advised us to ignore the gcc 
error message. The installation is done and the module is working.

2. We could not read datetime columns on RH6.2 because we had installed a 
DateTime module from somewhere I don't remember. It did not have the ISO 
module and that was the trouble. Today we installed mx rpm available for 
RH7.2 that also has the ISO module. Therefore the pypgsql is working fine.

Thanks again.
Have a nice day.
Dubal

On Monday 05 November 2001 01:05 pm, you wrote:
> dubal wrote:
> > Hello everyone,
> >
> > We have tried pygresql that is supplied with postgresql but we had
> > problems with quoting, nulls and checking rowcount after update
> > statement.
> >
> > We tried PoPy but we had problems with quoting and nulls.
> >
> > We tried this (pypgsql). We did not have any of the above problems.
> > However, we could not read any date columns from db.
>
> That is strange.  Can you post an example that illustrates the problem
> (table definition, code use to access the dates, etc.).
>
> > Also while installing, python2 setup.py build aborts with gcc
> > complaining: gcc: unrecognized option `-R/usr/lib/pgsql'
>
> The build doesn't abort, at least when I install it under cygwin using gcc.
> The message is just a warning and the option is ignored.
> ___________________________________________________________________________
> ____       | Billy G. Allie    | Domain....: Bil...@mu...
>
> |  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
> |-/-|----- | Dearborn, MI 48126|
> |/  |LLIE  | (313) 582-1540    |

Re: [Pypgsql-users] Help: Installation problems on RedHat 6.2 / 7.2

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

dubal wrote:
> Hello everyone,
> 
> We have tried pygresql that is supplied with postgresql but we had problems 
> with quoting, nulls and checking rowcount after update statement.
> 
> We tried PoPy but we had problems with quoting and nulls.
> 
> We tried this (pypgsql). We did not have any of the above problems.
> However, we could not read any date columns from db.

That is strange.  Can you post an example that illustrates the problem
(table definition, code use to access the dates, etc.).

> Also while installing, python2 setup.py build aborts with gcc complaining: 
> gcc: unrecognized option `-R/usr/lib/pgsql'

The build doesn't abort, at least when I install it under cygwin using gcc.
The message is just a warning and the option is ignored.
___________________________________________________________________________
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |

[Pypgsql-users] Help: Installation problems on RedHat 6.2 / 7.2

[dubal <du...@kh...>]

Hello everyone,

We have tried pygresql that is supplied with postgresql but we had problems 
with quoting, nulls and checking rowcount after update statement.

We tried PoPy but we had problems with quoting and nulls.

We tried this (pypgsql). We did not have any of the above problems.
However, we could not read any date columns from db.
Also while installing, python2 setup.py build aborts with gcc complaining: 
gcc: unrecognized option `-R/usr/lib/pgsql'

Please suggest a solution.
Any help is greatly appreciated.
Thanks in advance.

Dubal
du...@kh...

[Pypgsql-users] [ANN] pyPgSQL in FreeBSD ports collection

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

pyPgSQL is now part of the FreeBSD ports collection. I'm the maintainer
of this port.

A short explanation for those not familiar with the FreeBSD ports
concept:

In the next version of FreeBSD (or now in FreeBSD-current, if you like
to live on the bleeding edge), you will be able to simply go to
/usr/ports/databases/py-pyPgSQL and

- fetch the current release from Sourceforge and install it with "make
  install"
- build a package with "make package"

spreading-the-propaganda-ly yours,

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: [Pypgsql-users] Support for Large Objects in DBAPI Product

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

Bell John wrote:
> Does pypgsql support import/export operations on
> Binary Large Objects in the DB-API variant?  If so,
> what is the import/export syntax.
> 
> John

John,

The short answer is yes.

The long answer is more complicated.  Are you trying to import/export from a remote client or on the same machine on which the database resides (it makes a difference.

If on the same machine as the database server, you can use the built-in registered lo_import and lo_export.  This example is from the PostgreSQL documentation:

	CREATE TABLE image (
	    name            text,
	    raster          oid
	);

	INSERT INTO image (name, raster)
	    VALUES ('beautiful image', lo_import('/etc/motd'));

	SELECT lo_export(image.raster, '/tmp/motd') from image
	    WHERE name = 'beautiful image';

Just use the SQL insert and select statements in the execute() method.

If you need to import from a remote system, you can't us the lo_import or lo_export functions.  You can do the following (this requires the latest CVS of pyPgSQL to work):

	# Assume the the table image as defined above exists.
	from pyPgSQL import PgSQL
		cx = PgSQL.connect(database="dbname", host="hostname")
	cur = cx.cursor()
	# Import a file into a new large object.
	lo = cx.binary(open('/etc/motd', 'r').read())
	cur.execute('INSERT INTO image (name, raster) VALUES (%s, %s)',
		    'beautiful image', lo)
	cx.commit()

	# Export a large object to a file
	cur.execute('SELECT raster FROM image WHERE name = %s', "beautiful image")
	rs = cur.fetchone()
	lo = rs.raster
	lo.open('r')
	open('/tmp/motd', 'w').write(lo.read())

The lo_import and lo_export C-API functiona are available as methods of the libpq.PgConnection object.  If you are importing/exporting files that reside on the machine hosting the database server, you can use the follwoing code:

	from pyPgSQL import PgSQL
	cx = PgSQL.connect(database="dbname", host="hostname")
	cur = cx.cursor()
	# Import a file into a new large object.
	lo = cx.conn.lo_import('/etc/motd')
	cur.execute('INSERT INTO image (name, raster) VALUES (%s, %s)',
		    'beautiful image', lo)
	cx.commit()

	# Export a large object to a file
	cur.execute('SELECT raster FROM image WHERE name = %s', "beautiful image")
	rs = cur.fetchone()
	cx.conn.lo_export(rs.raster.oid, '/tmp/motd')

Again, I want to emphasize that the lo_export and lo_import will only export/import files that reside on the same machine as the database server.  Also, you will need to use the latest code from the CVS repository, which contains bug fixes related to large objects.

I hope this helps.
-- 
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |

[Pypgsql-users] Support for Large Objects in DBAPI Product

[Bell J. <jbe...@ya...>]

Does pypgsql support import/export operations on
Binary Large Objects in the DB-API variant?  If so,
what is the import/export syntax.

John

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Re: [Pypgsql-users] Re: PostgreSQL Interface Query

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

On Sun, Oct 14, 2001 at 03:18:55PM +1000, Stuart Bishop wrote:
> 
> On comp.lang.python at October 13, 2001, at 10:11  PM, Gerhard Häring wrote:
> 
> > On Sat, Oct 13, 2001 at 03:08:46PM +1000, Stuart Bishop wrote:
> >> On Saturday, October 13, 2001, at 02:05  PM, John Bell wrote:
> >>> [...]  I am leaning towards pypgsql [...]
> >>
> >> I got as far as checking its threadsafety - level 1 compliance
> >> is a major lack to me.
> >
> > I will look into the thread level compliance thing, but for now I only
> > remember a message from the main developer Bill Allie, which sounds
> > reasonable to me:
> >
> > http://mail.vex.net:99/pipermail/pygresql/2001-July/000420.html
> 
> If the PostgreSQL connection provided to you is not thread safe, then
> there is nothing stopping you using locking *inside* your connection
> object. The API says 'use a resource without wrapping it using a mutex
> semaphore', which is from the users perspective (the 'use' is the keyword
> - the connection is the resource).
> 
> And now that Gerhard's email made me realise that threadsafety level 1
> *is* perfectly good for Zope (I was counting from 1, not from 0), I have
> yet another postgres adaptor to evaluate :-)

Cool :-) There isn't an "official" ZOPE database adapter using pyPgSQL
at the moment. There will be one as a subproject of pyPgSQL soon,
however. At least as a development version in CVS.

A sneak preview of it and my experiments with Windows installers is
available at my homepage (sig). Btw. I will change the license from BSD
back to ZPL. I'm not sure if I really have to, but this is to be on the
safe side.

Oh, btw. it's based on the one from psycopg project and I only hacked it
for pyPgSQL.

Stay tuned :-)

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

[Pypgsql-users] Re: PostgreSQL Interface Query

[Stuart B. <ze...@sh...>]

On Saturday, October 13, 2001, at 10:11  PM, Gerhard H=E4ring wrote:

> On Sat, Oct 13, 2001 at 03:08:46PM +1000, Stuart Bishop wrote:
>> On Saturday, October 13, 2001, at 02:05  PM, John Bell wrote:
>>> [...]  I am leaning towards pypgsql [...]
>>
>> I got as far as checking its threadsafety - level 1 compliance
>> is a major lack to me.
>
> I will look into the thread level compliance thing, but for now I only
> remember a message from the main developer Bill Allie, which sounds
> reasonable to me:
>
> http://mail.vex.net:99/pipermail/pygresql/2001-July/000420.html

If the PostgreSQL connection provided to you is not thread safe, then
there is nothing stopping you using locking *inside* your connection
object. The API says 'use a resource without wrapping it using a mutex
semaphore', which is from the users perspective (the 'use' is the =
keyword
- the connection is the resource).

And now that Gerhard's email made me realise that threadsafety level 1
*is* perfectly good for Zope (I was counting from 1, not from 0), I have
yet another postgres adaptor to evaluate :-)

--
Stuart Bishop <ze...@sh...>

Re: [Pypgsql-users] why pypgsql??

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

markus jais wrote:
> hello
> just downloaded pypgsql
> looks really great.
> 
> a friend told my, that there are also some other 
> python interfaces to postgresql. some should be faster
> 
> I have not found any other and pypgsql is really good.
> but can somebody tell me, if there are other implementations
> too, and what advantages / disadvantages they have??

There are a number of other implementations around.  For example:  PyGreSQL, 
PoPy, and others.  PyGreSQL is part of the PostgreSQL distribution.  Links to 
others can be found at http://www.python.org/topics/database/modules.html.  
You can also look in the Vaults of Parnassus at http://www.vex.net/parnassus.  
Some are faster than others, and there are differing degrees of compliance 
with the DB-API 2.0 specifications.  Which one you chose will depend on your 
needs and requirements.  I can't give you any details about the other packages 
since I haven't looked at the lately so any comparisons I might make would 
likely contain out-dated information.
-- 
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |

[Pypgsql-users] why pypgsql??

[markus j. <in...@mj...>]

hello
just downloaded pypgsql
looks really great.

a friend told my, that there are also some other 
python interfaces to postgresql. some should be faster

I have not found any other and pypgsql is really good.
but can somebody tell me, if there are other implementations
too, and what advantages / disadvantages they have??

this would be really nice
thanks in advance

regards
markus

-- 
Markus Jais
http://www.mjais.de
in...@mj...
The road goes ever on and on - Bilbo Baggins

Re: [Pypgsql-users] Test message

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

On Mon, Oct 08, 2001 at 11:21:05AM -0400, Billy G. Allie wrote:
> Gerhard =3D?iso-8859-1?Q?H=3DE4ring?=3D wrote:
> > This is a test message. The mailing list page is now linked to from
> > http://pypgsql.sf.net/
> >=20
> > Gerhard
>=20
> Well, it looks like the test is successfull.
>=20
> BTW: I will be upgrading the hardware/OS on my machine within the next two
>      weeks, so I am unlikely to make any changes to it until that time (i=
.e.
>      the CVS for the web site will not be implemented for two weeks).  In
>      case your interested, I will be going to a dual Pentium-III 1ghz sys=
tem
>      with 2Gbytes ram.  The OS will be Caldera OpenUnix 8 (formally know =
as
>      UnixWare).

Wow! Preparing for VA Linux going broke and Sourceforge disappearing? ;-)

And I thought my dual-Celeron 500 w/ 512 MB RAM was a killer machine.

ciao,

Gerhard
--=20
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'=
)))

Re: [Pypgsql-users] Test message

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

Gerhard =?iso-8859-1?Q?H=E4ring?= wrote:
> This is a test message. The mailing list page is now linked to from
> http://pypgsql.sf.net/
> 
> Gerhard

Well, it looks like the test is successfull.

BTW: I will be upgrading the hardware/OS on my machine within the next two
     weeks, so I am unlikely to make any changes to it until that time (i.e.
     the CVS for the web site will not be implemented for two weeks).  In
     case your interested, I will be going to a dual Pentium-III 1ghz system
     with 2Gbytes ram.  The OS will be Caldera OpenUnix 8 (formally know as
     UnixWare).

Later.
___________________________________________________________________________
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |

[Pypgsql-users] Test message

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

This is a test message. The mailing list page is now linked to from
http://pypgsql.sf.net/

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))