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

[Pypgsql-users] [PATCH] Fix _quote to accept subclasses of 'str' and 'long'

[Pinchart, L. <Pin...@PC...>]

Oops, sorry, forgot to attach the patch.

Hi,

Here's a patch that fixes a problem in _quote for instances of a subclass of
'str'.

pyPgSQL quotes values depending on their type, and uses type() to check the
value type. Because of that, instances of a subclass of 'str' are not
processed by PgQuoteString like they should. I noticed the problem because
util.FieldStorage in mod_python returns instances of a class called
'StringField', which is a subclass of 'str'.

The patch also contains a fix for Connection.unlink that hadn't been
commited from my last patch. As I received no negative comment about it, I
assume that it had been forgotten. Please comment if something is wrong.

Laurent Pinchart

[Pypgsql-users] [PATCH] Fix _quote to accept subclasses of 'str' and 'long'

[Pinchart, L. <Pin...@PC...>]

Hi,

Here's a patch that fixes a problem in _quote for instances of a subclass of
'str'.

pyPgSQL quotes values depending on their type, and uses type() to check the
value type. Because of that, instances of a subclass of 'str' are not
processed by PgQuoteString like they should. I noticed the problem because
util.FieldStorage in mod_python returns instances of a class called
'StringField', which is a subclass of 'str'.

The patch also contains a fix for Connection.unlink that hadn't been
commited from my last patch. As I received no negative comment about it, I
assume that it had been forgotten. Please comment if something is wrong.

Laurent Pinchart

[Pypgsql-users] pyPgSQL works with MSVC6 compiled libpq now -- was Re: [Pypgsql-users] Re: Can't connect using Win95 client

[<gh...@gh...>]

Gerhard Häring wrote:
> Pinchart, Laurent wrote:
> 
>> Yes I did (to fix a problem for which I submitted a patch). That's 
>> probably
>> the cause of the problem, as I don't remember having encountered it 
>> before.
>>
>> I compiled libpq using Visual Studio 6 (nmake -f win32.mak), and then
>> compiled pyPgSQL using the same compiler (python setup.py build).
> 
> I'll try to look into this on the weekend. [...]

The problem Problem solved and fixed in CSV. It was indeed a pretty 
strange one as well:

In fact, the problem was with my mingw patch for libpq, not with 
pyPgSQL. pyPgSQL shouldn't have worked in the first place. Ok, it was 
pretty clear that a call to WSAStartup was missing, but why the hell did 
the mingw build work ok, then? The reason was that my mingw patch for 
libpq included the libpdll.c file in both the DLL version *and* the 
static version. This file contains a function DllMain. Now if you 
compiled pyPgSQL statically against libpq, this DllMain function was 
linked in into pyPgSQL/libpq/libpq.pyd. Of course this DllMain does the 
necessary WSAStartup/WSACleanup calls. The MSVC build was missing this 
DLLMain and thus the WSAStartup call.

Now of course the proper solution was for me to fix my mingw/libpq 
patch, which I did and uploaded to http://pypgsql.sf.net/misc/

Of course the WSAStartup/Cleanup call needed to go into pyPgSQL and this 
I did. I just put the PostgreSQL code into the pyPgSQL C layer and 
everything is fine now. I tested all combinations and all work:

MSVC6:	statically + dynamically linked against libpq
mingw:  statically + dynamically linked against libpq

I have no idea about the original Windows 95 problem this thread started 
with. All I can recommend is that SP1 for Win95 is installed. It 
includes some Winsock fixes.

-- Gerhard

RE: [Pypgsql-users] Re: Can't connect using Win95 client

[Pinchart, L. <Pin...@PC...>]

> > When building pypgsql with mingw, I get lots of undefined =
references at
> > linking:
> >=20
> > [...]
> >=20
> =
build\temp.win32-2.2\Release\libpqmodule.o(.text+0x620):libpqmodule.c:
> > r=E9f=E9rence
> >  ind=E9finie vers =AB _imp__PyExc_ValueError =BB
> > [...]
>=20
> Have you created an import library for mingw like described at=20
>
http://www.python.org/doc/current/inst/non-ms-compilers.html#SECTION0003=
1200
0000000000000 ?

I hadn't done it.

> To build libpq using mingw, get the PostgreSQL 7.3 sources,=20
> unzip them in .. as relative from the pyPgSQL directory, rename the=20
> directory from  'postgresql-7.3.2' or whatever it is to 'postgresql', =
then
apply the=20
> patch I talked about below
http://pypgsql.sourceforge.net/misc/win32_mingw32_makefiles_73.dif=20
> You'll need a 'patch' executable, like the one in Cygwin.
>=20
> Then go into the 'postgresql' directory and say
>=20
> make -f mingw32.mak
>=20
> This will build PostgreSQL's libpq.

Shouldn't it be in postgresql/src instead ?

I moved mingw32.make to postgresql/src, and did a make -f mingw32.mak. =
The
built process succeeded (I got errors at link time, but a global make =
clean
before compiling got rid of them).

Building pypgsql using that new libpq.a solved the WSAStartup problem.

> Anyway I'll try to look into the MSVC issue on the weekend.

I don't know if it's related to the PostgreSQL libpq, or to pyPgSQL
libpq.pyd.

Laurent Pinchart

Re: [Pypgsql-users] Help needed on performance

[Dick K. <D.J...@ch...>]

Hi,

I think this is the wrong list for this question. Go to the Postgres
lists. (Not that I'm not willing to help). It looks to me as a real
Postgres problem. Tuning of a database is a very specialized field, and
turning some knobs on the database sometimes drastically improves (or
deteriorates) performance.

Wish you luck.

Dick

On Fri, 2003-06-13 at 08:04, Dave Strickler wrote:
> If there's a good FAQ on this, please just point me there....
>  
> Background
> ------------
> I have a database that has 3 tables in it. One of the tables has about
> 15-20 fields in it, a number of them are strings, and so I have defined
> them as TEXT. The others are mostly INT4.
> I have indexes on 4 of the TEXT fields, and on one other INT4 fields. 
>  
> The table has 500k to 1m (size fluxuates) rows in it and is run on a
> Dual Processor 2.4 Xenon, with 2GB of RAM and a single IDE drive. Its
> running RH8, and has Apache running as well as Postgresql.
> 
>  
>  
> Problem
> ----------
> The crux of the problem is performance. At somewhere around 500k
> records in the table, the speed of SELECTs and DELETEs gets really poor.
> 'Poor' as in 2-3 minutes to do a DELETE of 1k rows. Under this number,
> the speed is excellent.
>  
> Any ideas on this?
>  
> TIA,
>  
>  
>  
> Dave Strickler 
> MailWise, LLC
> (617) 848-5942
> ------------------------------------
> Want to get rid of SPAM, Viruses, and unwanted content?
> MailWise Filter - nothing to install, maintain or upgrade.
> "Intelligent Email Protection(tm)" 
> Info at  http://www.mailwise.com
> ----
> 

> BEGIN:VCARD
> VERSION:2.1
> X-GWTYPE:USER
> FN:Dave Strickler
> TEL;WORK:617-267-0044 Ext. 10
> TEL;PREF;FAX:617-267-0055
> EMAIL;WORK;PREF;NGW:Dst...@ma...
> N:Strickler;Dave
> TITLE:President - DWS / MailWise
> END:VCARD
> 

Re: [Pypgsql-users] Re: Can't connect using Win95 client

[<gh...@gh...>]

Pinchart, Laurent wrote:
>>Yes, mingw. I have access to MSVC6 and 7, but don't normally use them 
>>for open-source projects.
> 
> When building pypgsql with mingw, I get lots of undefined references at
> linking:
> 
> [...]
> build\temp.win32-2.2\Release\libpqmodule.o(.text+0x620):libpqmodule.c:
> référence
>  indéfinie vers « _imp__PyExc_ValueError »
> [...]

Have you created an import library for mingw like described at 
http://www.python.org/doc/current/inst/non-ms-compilers.html#SECTION000312000000000000000
?

> libpq.a has been built using gcc/cygwin (if there's a way to build it with
> mingw please let me know). I'm not experienced with mingw, so any help would
> be appreciated.

To build libpq using mingw, get the PostgreSQL 7.3 sources, unzip them 
in .. as relative from the pyPgSQL directory, rename the directory from 
'postgresql-7.3.2' or whatever it is to 'postgresql', then apply the 
patch I talked about below 
http://pypgsql.sourceforge.net/misc/win32_mingw32_makefiles_73.dif 
You'll need a 'patch' executable, like the one in Cygwin.

Then go into the 'postgresql' directory and say

make -f mingw32.mak

This will build PostgreSQL's libpq.

Then you can go into the pyPgSQL directory and build pyPgSQL with

python setup.py build --compiler=mingw32

That's the complete process AFAIK.

Anyway I'll try to look into the MSVC issue on the weekend.

>>I also build my own statically linked libpq using the latest 
>>PostgreSQL 
>>sources and my mingw patch for it: 
>>http://pypgsql.sourceforge.net/misc/postgresql.html

Amicalement,

-- Gerhard

RE: [Pypgsql-users] Re: Can't connect using Win95 client

[Pinchart, L. <Pin...@PC...>]

> Yes, mingw. I have access to MSVC6 and 7, but don't normally use them =

> for open-source projects.

When building pypgsql with mingw, I get lots of undefined references at
linking:

[...]
build\temp.win32-2.2\Release\libpqmodule.o(.text+0x620):libpqmodule.c:
r=E9f=E9rence
 ind=E9finie vers =AB _imp__PyExc_ValueError =BB
build\temp.win32-2.2\Release\libpqmodule.o(.text+0x86d):libpqmodule.c:
r=E9f=E9rence
 ind=E9finie vers =AB _imp__PyExc_MemoryError =BB
build\temp.win32-2.2\Release\libpqmodule.o(.text+0xf50):libpqmodule.c:
r=E9f=E9rence
 ind=E9finie vers =AB _imp__PyInt_Type =BB
build\temp.win32-2.2\Release\libpqmodule.o(.text+0xf5a):libpqmodule.c:
r=E9f=E9rence
 ind=E9finie vers =AB _imp__PyInt_Type =BB
build\temp.win32-2.2\Release\libpqmodule.o(.text+0xf87):libpqmodule.c:
r=E9f=E9rence
 ind=E9finie vers =AB _imp__PyLong_Type =BB
build\temp.win32-2.2\Release\libpqmodule.o(.text+0xf91):libpqmodule.c:
r=E9f=E9rence
 ind=E9finie vers =AB _imp__PyLong_Type =BB
[...]

libpq.a has been built using gcc/cygwin (if there's a way to build it =
with
mingw please let me know). I'm not experienced with mingw, so any help =
would
be appreciated.

> I also build my own statically linked libpq using the latest=20
> PostgreSQL=20
> sources and my mingw patch for it:=20
> http://pypgsql.sourceforge.net/misc/postgresql.html

Thanks

Re: [Pypgsql-users] Re: Can't connect using Win95 client

[<gh...@gh...>]

Pinchart, Laurent wrote:
>>I haven't used MSVC for ages to compile pyPgSQL, though.
> 
> What do you use to make the win32 binary package ? mingw ?

Yes, mingw. I have access to MSVC6 and 7, but don't normally use them 
for open-source projects.

I also build my own statically linked libpq using the latest PostgreSQL 
sources and my mingw patch for it: 
http://pypgsql.sourceforge.net/misc/postgresql.html

-- Gerhard

RE: [Pypgsql-users] Re: Can't connect using Win95 client

[Pinchart, L. <Pin...@PC...>]

> I haven't used MSVC for ages to compile pyPgSQL, though.

What do you use to make the win32 binary package ? mingw ?

Laurent Pinchart

Re: [Pypgsql-users] Re: Can't connect using Win95 client

[<gh...@gh...>]

Pinchart, Laurent wrote:
> Yes I did (to fix a problem for which I submitted a patch). That's probably
> the cause of the problem, as I don't remember having encountered it before.
> 
> I compiled libpq using Visual Studio 6 (nmake -f win32.mak), and then
> compiled pyPgSQL using the same compiler (python setup.py build).

I'll try to look into this on the weekend.

I haven't used MSVC for ages to compile pyPgSQL, though.

Probably the instructions in the win32 README need to be more specific.

Later,

-- Gerhard

Re: [Pypgsql-users] Help needed on performance

[Bob K. <bo...@ip...>]

Hi!

The only thing that comes immediately to mind is to be sure that you're 
vacuuming regularly. It seems to me that you're inserting and deleting rows 
quite a bit, and without regular vacuuming, the indexes will become pretty 
useless. I had similar problems with a table that had only a few dozen rows, 
but a couple hundred thousand deleted rows. Performance was horrible until I 
remembered to vacuum, which I now do daily with a cron job. I don't think 
Pypgsql has any bearing on the problem, however.

HTH.

.... Bob

On Friday 13 June 2003 02:04, Dave Strickler wrote:
> If there's a good FAQ on this, please just point me there....
>
> Background
> ------------
> I have a database that has 3 tables in it. One of the tables has about
> 15-20 fields in it, a number of them are strings, and so I have defined
> them as TEXT. The others are mostly INT4.
> I have indexes on 4 of the TEXT fields, and on one other INT4 fields.
>
> The table has 500k to 1m (size fluxuates) rows in it and is run on a
> Dual Processor 2.4 Xenon, with 2GB of RAM and a single IDE drive. Its
> running RH8, and has Apache running as well as Postgresql.
>
>
>
> Problem
> ----------
> The crux of the problem is performance. At somewhere around 500k
> records in the table, the speed of SELECTs and DELETEs gets really poor.
> 'Poor' as in 2-3 minutes to do a DELETE of 1k rows. Under this number,
> the speed is excellent.
>
> Any ideas on this?
>
> TIA,
>
>
>
> Dave Strickler
> MailWise, LLC
> (617) 848-5942
> ------------------------------------
> Want to get rid of SPAM, Viruses, and unwanted content?
> MailWise Filter - nothing to install, maintain or upgrade.
> "Intelligent Email Protection(tm)"
> Info at  http://www.mailwise.com

RE: [Pypgsql-users] Re: Can't connect using Win95 client

[Pinchart, L. <Pin...@PC...>]

> > [Win95 and host name resolution]
> > I experienced the same problem today in Windows 2000.
> 
>  From what I see, this is a totally different problem.

You're probably right.

> >>>>PgSQL.connect(host="localhost", database="Test")
> > 
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> >   File 
> "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2118, in
> > connect
> >     return Connection(connInfo, client_encoding, unicode_results)
> >   File 
> "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2215, in
> > __init__
> >     raise DatabaseError, m
> > libpq.DatabaseError: unknown host name: localhost
> 
> That's very strange. Have you compiled pyPgSQL yourself from sources? 
> Have you linked it dynamically against libpq? The binaries I 
> offer on SF are built *statically* against libpq and do not suffer from 
> this problem.

Yes I did (to fix a problem for which I submitted a patch). That's probably
the cause of the problem, as I don't remember having encountered it before.

I compiled libpq using Visual Studio 6 (nmake -f win32.mak), and then
compiled pyPgSQL using the same compiler (python setup.py build).

There must be something wrong though, because the version of libpq.pyd that
I compiled myself seems to use the GUI subsystem, while the one in the
binary package uses Console. There are a few more differences (linker
version for instance, 6.0 for me, 2.56 for you).

There's also a difference regarding to wsock32.dll. My version of libpq.pyd
imports wsock32.dll using ordinal imports, while yours directly reference
the functions. My version doesn't reference WSAStartup while yours does.

Is there something I did wrong ? I modified setup.py according to the
instructions inside the file for Visual Studio (setup.py uses mingw by
defaults).

> Which PostgreSQL version do you link against?

7.3.2.

Laurent Pinchart

[Pypgsql-users] RE: Transaction problems with large objects in PgSQLpy

[Pinchart, L. <Pin...@PC...>]

> In regards to the problem  in Connection.binary, which commits a
transaction
> if it has started one, but doesn't reset the "inTransaction" flag to 0:
>
> After some thought, I now believe that the transaction should not be
committed
> after the large object is created. This would push the responsibility of
commiting
> the transactiont to the application programmer. The sequence would usually
be:

I agree

Laurent Pinchart

[Pypgsql-users] Re: Transaction problems with large objects in PgSQLpy

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

In regards to the problem  in Connection.binary, which commits a 
transaction if it has started one, but doesn't reset the "inTransaction" 
flag to 0:

After some thought, I now believe that the transaction should not be 
committed after the large object is created. This would push the 
responsibility of commiting the transactiont to the application 
programmer. The sequence would usually be:

   1.  (optionally) perform some queries or updates.
   2.  create the large object.
   3. store the new large object in a table
   4. (optionally) perform other queries and updates.
   5. commit (or rollback) the transaction.

This change will allow the creation of the large object to be rolled 
back if a problem occurs after it's creation. Currently, the large 
object is commited before it is returned to the application, which, 
IMHO, is not the way it should be.

BTW:  This code was written this way when loage objects could not be 
succefully rolled back in PostgreSQL.  This is no longer the case.

Commets anyone?
------------------------------------------------------------------------
In regards to the problem is in Connection.unlink which should raise a 
NotSupportedError exception when a called from within a transaction in 
PostgreSQL < 7.1.0, I will apply the patch.

___________________________________________________________________________

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

[Pypgsql-users] Help needed on performance

[Dave S. <dst...@ma...>]

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Dave Strickler
TEL;WORK:617-267-0044 Ext. 10
TEL;PREF;FAX:617-267-0055
EMAIL;WORK;PREF;NGW:Dst...@ma...
N:Strickler;Dave
TITLE:President - DWS / MailWise
END:VCARD

[Pypgsql-users] Re: Can't connect using Win95 client

[Chris W. <cw...@cf...>]

Thanks Laurent,

I'll try the socket trick first thing tomorrow. Odd that the
Win98 clients have no problems here.  I don't know if Gerhard's
question was directed at me, but on the windows clients I'm
using strictly the "canned" installs from the parent web sites.
I have no windows build capabilities at all.

Regards,

Chris



On Thu, 2003-06-12 at 10:53, Pinchart, Laurent wrote:
> > >>   File "C:\Python22\Lib\site-packages\pyPgSQL\PgSQL.py", 
> > line 2118, in
> > >> connect
> > >>     return Connection(connInfo, client_encoding, unicode_results)
> > >>   File "C:\Python22\Lib\site-packages\pyPgSQL\PgSQL.py", 
> > line 2215, in
> > >> __init__
> > >>     raise DatabaseError, m
> > >> libpq.DatabaseError: unknown host name: 192.168.1.160
> 
> I experienced the same problem today in Windows 2000.
> 
> ----------------------------------------------------------------------------
> ------
> $ python
> Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from pyPgSQL import PgSQL
> >>> PgSQL.connect()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2118, in
> connect
>     return Connection(connInfo, client_encoding, unicode_results)
>   File "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2215, in
> __init__
>     raise DatabaseError, m
> libpq.DatabaseError: could not create socket: WSAStartup not yet called
> (0x00002
> 76D/10093)
> 
> >>> PgSQL.connect(host="localhost", database="Test")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2118, in
> connect
>     return Connection(connInfo, client_encoding, unicode_results)
>   File "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2215, in
> __init__
>     raise DatabaseError, m
> libpq.DatabaseError: unknown host name: localhost
> 
> >>> import socket
> >>> PgSQL.connect(host="localhost", database="Test")
> <pyPgSQL.PgSQL.Connection instance at 0x008359D0>
> >>>
> ----------------------------------------------------------------------------
> ------
> 
> It seems that pyPgSQL forgets to initialize Winsock (WSAStartup). Or should
> libpq do it ? This should be investigated.
> 
> Anyway, for a quick workaround, just import socket and it should work
> properly.
> 
> Laurent Pinchart
-- 
Chris Wren <cw...@cf...>

Re: [Pypgsql-users] Re: Can't connect using Win95 client

[<gh...@gh...>]

Pinchart, Laurent wrote:
> [Win95 and host name resolution]
> I experienced the same problem today in Windows 2000.

 From what I see, this is a totally different problem.

> ----------------------------------------------------------------------------
> ------
> $ python
> Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> 
>>>>from pyPgSQL import PgSQL
>>>>PgSQL.connect()
> 
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2118, in
> connect
>     return Connection(connInfo, client_encoding, unicode_results)
>   File "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2215, in
> __init__
>     raise DatabaseError, m
> libpq.DatabaseError: could not create socket: WSAStartup not yet called
> (0x00002
> 76D/10093)

I cannot reproduce this:

#v+
C:\>python
Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> from pyPgSQL import PgSQL
 >>> PgSQL.connect()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "c:\python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2118, in 
connect
     return Connection(connInfo, client_encoding, unicode_results)
   File "c:\python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2215, in 
__init__
     raise DatabaseError, m
libpq.DatabaseError: could not create socket: Address family not 
supported (0x00
00273F/10047)
#v-

This is clear, because Windows doesn't support Unix domain sockets, so 
you *always* have to use a hostname on win32, even if a native or Cygwin 
PostgreSQL server is running on localhost.

>>>>PgSQL.connect(host="localhost", database="Test")
> 
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2118, in
> connect
>     return Connection(connInfo, client_encoding, unicode_results)
>   File "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2215, in
> __init__
>     raise DatabaseError, m
> libpq.DatabaseError: unknown host name: localhost

That's very strange. Have you compiled pyPgSQL yourself from sources? 
Have you linked it dynamically against libpq? The binaries I offer on SF 
are built *statically* against libpq and do not suffer from this problem.

Which PostgreSQL version do you link against?

-- Gerhard

RE: [Pypgsql-users] Re: Can't connect using Win95 client

[Pinchart, L. <Pin...@PC...>]

> >>   File "C:\Python22\Lib\site-packages\pyPgSQL\PgSQL.py", 
> line 2118, in
> >> connect
> >>     return Connection(connInfo, client_encoding, unicode_results)
> >>   File "C:\Python22\Lib\site-packages\pyPgSQL\PgSQL.py", 
> line 2215, in
> >> __init__
> >>     raise DatabaseError, m
> >> libpq.DatabaseError: unknown host name: 192.168.1.160

I experienced the same problem today in Windows 2000.

----------------------------------------------------------------------------
------
$ python
Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from pyPgSQL import PgSQL
>>> PgSQL.connect()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2118, in
connect
    return Connection(connInfo, client_encoding, unicode_results)
  File "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2215, in
__init__
    raise DatabaseError, m
libpq.DatabaseError: could not create socket: WSAStartup not yet called
(0x00002
76D/10093)

>>> PgSQL.connect(host="localhost", database="Test")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2118, in
connect
    return Connection(connInfo, client_encoding, unicode_results)
  File "D:\Soft\Python22\lib\site-packages\pyPgSQL\PgSQL.py", line 2215, in
__init__
    raise DatabaseError, m
libpq.DatabaseError: unknown host name: localhost

>>> import socket
>>> PgSQL.connect(host="localhost", database="Test")
<pyPgSQL.PgSQL.Connection instance at 0x008359D0>
>>>
----------------------------------------------------------------------------
------

It seems that pyPgSQL forgets to initialize Winsock (WSAStartup). Or should
libpq do it ? This should be investigated.

Anyway, for a quick workaround, just import socket and it should work
properly.

Laurent Pinchart

[Pypgsql-users] Re: Can't connect using Win95 client

[Chris W. <cw...@cf...>]

Greetings,

Thanks much for the suggestion - it put me on the right track.

Adding the hosts file, and rebooting had no effect. But, Bob
guessed that it was some sort of host resolution problem.
So I edited the code from '192.168.1.160' to 'blah.xyz.com',
forcing the Win95 box to hit our local DNS server, and it
connected fine. Weird. Even weirder - the mail client (mozilla)
on this same box is pointed by IP address to our mail server -
and it works fine. So is it a Win95 TCP/IP problem? Hmm...

Thanks for your time - I'd love a solution, but I'll settle
for a fix, and you got me there.

Regards,

Chris



> My guess is that the Windows 95 TCP/IP stack isn't figuring out that 
> 192.168.1.160 is a TCP/IP address instead of a host name. Perhaps you could 
> put an entry in your hosts file -- c:\windows\hosts or some such thing -- and 
> that might trick the TCP/IP stack into resolving the IP address. You should 
> find c:\windows\hosts.sam file, which you can copy to c:\windows\hosts as a 
> start if you don't already have one.
> 
> I think good practice is to have a localhost entry, so your hosts file should 
> have at least the following two entries:
> 
> 127.0.0.1  localhost
> 192.168.1.160  foo
> 
> where "foo" is an arbitrary name for your PostgreSQL server.
> 
> HTH.
> 
> .... Bob
> 
> On Wednesday 11 June 2003 22:49, Chris Wren wrote:
>> Greetings,
>>
>> I am having trouble connecting to a FreeBSD PostGreSQL server
>> using a Windows 95 client.
>>
>> The code runs _fine_ on several Win98 clients on the same network.
>> The command that breaks is as follows:
>>
>> _______
>>
>>  self.db = PgSQL.connect( user = self.uid,  host = self.hostname,
>> database = self.dbname, password = self.pwd )
>> ________
>>
>> The error message I get is as follows:
>> ______
>>
>>   File "C:\Python22\Lib\site-packages\pyPgSQL\PgSQL.py", line 2118, in
>> connect
>>     return Connection(connInfo, client_encoding, unicode_results)
>>   File "C:\Python22\Lib\site-packages\pyPgSQL\PgSQL.py", line 2215, in
>> __init__
>>     raise DatabaseError, m
>> libpq.DatabaseError: unknown host name: 192.168.1.160
>>
>> ________
>>
>> Here are the relevant software versions:
>>
>> ________
>>
>> Client:
>> Windows 95
>> ActivePython 2.2.2 build 224
>> egenix-mx-base-2.0.4.win32-py2.2
>> pyPgSQL-2.3.win32-py2.2
>> wxPythonWIN32-2.4.0.7-Py22
>>
>> Server:
>> IP: 192.168.1.160
>> FreeBSD 4.7
>> postgresql-7.2.1_1
>>
>> __________
>>
>> The Win 95 box seems to have good network connectivity,
>> at least it happily accesses a SAMBA server running on the
>> same FreeBSD box as the database.
>>
>> Any clues are, as always, much appreciated.
>>
>> Thanks,
>>
>> Chris
>>

[Pypgsql-users] [PATCH] Fix misinterpretation of lo_unlink and lo_export return v alues in pgconnection.c

[Pinchart, L. <Pin...@PC...>]

Hi,

Here's a patch (against CVS HEAD) that fixes a misinterpretation of the
lo_unlink and lo_export return values in pgconnection.c.

Those functions return -1 when an error occurs, and 1 when successful, while
pgconnection.c assumed that any return value other than 0 was an error.

I haven't tested thepatch completely yet, but I checked that
Connection.unlink raised an exception while still deleting the large object.

Laurent Pinchart

[Pypgsql-users] [PATCH] Transaction problems with large objects in PgSQL.py

[Pinchart, L. <Pin...@PC...>]

Hi,

Here's a patch that fixes two transaction problems in PgSQL.py.

The first problem is in Connection.binary, which commits a transaction if it
has started one, but doesn't reset the "inTransaction" flag to 0. The
Connection object thus thinks that we are still in a transaction when we are
not, and fails to begin a new transaction on the next cursor open operation.

The second problem is in Connection.unlink which should raise a
NotSupportedError exception when a called from within a transaction in
PostgreSQL < 7.1.0. The version check actually raise an exception when the
PostgreSQL version is >= 7.1.0 OR when a transaction is NOT in progress,
instead of when the PostgreSQL version is NOT >= 7.1.0 AND a transaction is
in progress.

The attached patch is against the latest CVS version.

Laurent Pinchart

Re: [Pypgsql-users] Can't connect using Win95 client

[Bob K. <bo...@ip...>]

My guess is that the Windows 95 TCP/IP stack isn't figuring out that 
192.168.1.160 is a TCP/IP address instead of a host name. Perhaps you could 
put an entry in your hosts file -- c:\windows\hosts or some such thing -- and 
that might trick the TCP/IP stack into resolving the IP address. You should 
find c:\windows\hosts.sam file, which you can copy to c:\windows\hosts as a 
start if you don't already have one.

I think good practice is to have a localhost entry, so your hosts file should 
have at least the following two entries:

127.0.0.1  localhost
192.168.1.160  foo

where "foo" is an arbitrary name for your PostgreSQL server.

HTH.

.... Bob

On Wednesday 11 June 2003 22:49, Chris Wren wrote:
> Greetings,
>
> I am having trouble connecting to a FreeBSD PostGreSQL server
> using a Windows 95 client.
>
> The code runs _fine_ on several Win98 clients on the same network.
> The command that breaks is as follows:
>
> _______
>
>  self.db = PgSQL.connect( user = self.uid,  host = self.hostname,
> database = self.dbname, password = self.pwd )
> ________
>
> The error message I get is as follows:
> ______
>
>   File "C:\Python22\Lib\site-packages\pyPgSQL\PgSQL.py", line 2118, in
> connect
>     return Connection(connInfo, client_encoding, unicode_results)
>   File "C:\Python22\Lib\site-packages\pyPgSQL\PgSQL.py", line 2215, in
> __init__
>     raise DatabaseError, m
> libpq.DatabaseError: unknown host name: 192.168.1.160
>
> ________
>
> Here are the relevant software versions:
>
> ________
>
> Client:
> Windows 95
> ActivePython 2.2.2 build 224
> egenix-mx-base-2.0.4.win32-py2.2
> pyPgSQL-2.3.win32-py2.2
> wxPythonWIN32-2.4.0.7-Py22
>
> Server:
> IP: 192.168.1.160
> FreeBSD 4.7
> postgresql-7.2.1_1
>
> __________
>
> The Win 95 box seems to have good network connectivity,
> at least it happily accesses a SAMBA server running on the
> same FreeBSD box as the database.
>
> Any clues are, as always, much appreciated.
>
> Thanks,
>
> Chris
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Pypgsql-users mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypgsql-users

[Pypgsql-users] Can't connect using Win95 client

[Chris W. <cw...@cf...>]

Greetings,

I am having trouble connecting to a FreeBSD PostGreSQL server
using a Windows 95 client.

The code runs _fine_ on several Win98 clients on the same network.
The command that breaks is as follows: 

_______

 self.db = PgSQL.connect( user = self.uid,  host = self.hostname,
database = self.dbname, password = self.pwd )
________

The error message I get is as follows:
______

  File "C:\Python22\Lib\site-packages\pyPgSQL\PgSQL.py", line 2118, in
connect
    return Connection(connInfo, client_encoding, unicode_results)
  File "C:\Python22\Lib\site-packages\pyPgSQL\PgSQL.py", line 2215, in
__init__
    raise DatabaseError, m
libpq.DatabaseError: unknown host name: 192.168.1.160

________

Here are the relevant software versions:

________

Client:
Windows 95
ActivePython 2.2.2 build 224
egenix-mx-base-2.0.4.win32-py2.2
pyPgSQL-2.3.win32-py2.2
wxPythonWIN32-2.4.0.7-Py22

Server:
IP: 192.168.1.160
FreeBSD 4.7
postgresql-7.2.1_1

__________

The Win 95 box seems to have good network connectivity,
at least it happily accesses a SAMBA server running on the
same FreeBSD box as the database.

Any clues are, as always, much appreciated.

Thanks,

Chris

Re: [Pypgsql-users] executemany question

[<gh...@gh...>]

Steve Waterbury wrote:
> Gerhard Häring wrote:
>> executemany is not supposed to be used with SELECTs. Use it for INSERT 
>> or UPDATE only.
> 
> Thanks ... I realized that right after I send my
> question!  :^)
> 
>> [...]
>> In your particular example:
>>
>> docnums = [3,4,5,6]
>> curs.execute("select * from docs where doc_number in %s", (docnums,))
> 
> 
> That doesn't seem to work either: [...]

Sorry, I meant to use a tuple instead of a list. So pyPgSQL will invoke 
repr() on the parameter before inserting it into the SQL. AFAIC this 
will currently work fine for ints and floats, but not much else. Also 
note that this is one thing that won't work in other adapters like for 
Oracle.

But you can always construct your SQL with the appropriate IN-clause 
manually.

-- Gerhard

Re: [Pypgsql-users] Using Python for stored procedures (functions)

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

Sean Reifschneider wrote:

>I can't get this message past the spam checks for header from versus
>envelope sender.  I'd appreciate it if you could forward it to the list.
>
>Thanks,
>Sean
>
>--- Below this line is a copy of the message.
>
>Return-Path: <ja...@tu...>
>Received: (qmail 7192 invoked by uid 10); 1 May 2003 23:04:50 -0000
>Received: (qmail 6921 invoked by uid 500); 1 May 2003 23:04:47 -0000
>Date: Thu, 1 May 2003 17:04:47 -0600
>From: Sean Reifschneider <jaf...@gu...>
>To: Jorge Godoy <go...@me...>
>Cc: pyp...@li...
>Subject: Re: [Pypgsql-users] Using Python for stored procedures (functions)
>Message-ID: <200...@tu...>
>References: <86z...@ie...>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <86z...@ie...>
>User-Agent: Mutt/1.4.1i
>
>On Fri, Apr 25, 2003 at 08:28:31PM -0300, Jorge Godoy wrote:
>  
>
>>Sorry if this is off topic here, but is there anyone using Python to
>>implement complex stored procedures (or functions) in PostgreSQL? I'm
>>starting with it and I'd like to hear is someone's doing it instead of
>>puttong the whole logic outside the database.
>>    
>>
>
>I'm using it just a little.  Basically, I'm using it because you can't
>use pl/pgsql for implementing trigger functions, so I wrapped some
>simple SQL in Python and used that.
>
>The one caveat I would have for you is that the python crew is retiring
>the rexec stuff because of lack of maintainership and due to security
>problems, but pl/python uses that.  So, I'm not sure what the future of
>pl/python is...
>
>Sean
>  
>
-- 
___________________________________________________________________________
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |