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

Re: [Pypgsql-users] Curious Win32 timestamp shift

[Karsten H. <Kar...@gm...>]

On Thu, Jun 21, 2007 at 02:46:32PM +1000, Kingsley wrote:

> I'm using PyPgSQL against a table that has a 'timestamp' type
> field.  Under Linux I have no problems, but when results are
> returned from the database under win32, they are shifted by +10 hours
> (This is also happens to be my timezone.)  I have not applied a
> timezone to the timestamp-type field.  Interestingly, they are
> being stored correctly, just not retrieved properly.
> 
> The times in the database are indeed stored in UTC, but PyPgSQL doesn't 
> know this ;)

You may just be lucky to retrieve "proper" values under
Linux. In any case you'll have to tell PG which timezone the
client is running under or else the default server timezone
is used to return timestamps in - which may happen to work
with Linux but not Windows.

So, use "set client timezone to ..." somewhere appropriate
in your connection setup.

Or else always retrieve timestamps with the "AT timezone" syntax.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

[Pypgsql-users] Curious Win32 timestamp shift

[Kingsley <kr...@kr...>]

Hi-ho,

I'm using PyPgSQL against a table that has a 'timestamp' type
field.  Under Linux I have no problems, but when results are
returned from the database under win32, they are shifted by +10 hours
(This is also happens to be my timezone.)  I have not applied a
timezone to the timestamp-type field.  Interestingly, they are
being stored correctly, just not retrieved properly.

The times in the database are indeed stored in UTC, but PyPgSQL doesn't
know this ;)

Any suggestions as to why this should happen only under Windows?
How about hints on how to fix it?

I could always kludge in an:
	timestamp - interval '-36000 seconds'
Type fix, but that's very dodgey.
(even if the timeshift is from time.timezone)

The timezone is set under windows, as it is under Linux.
(GMT+10 / Sydney, NSW)

I'm using "pyPgSQL-pre2.5-20050926.win32-py2.4.exe"
as the latest version crashes my (py2exe) exe, during "import pyPgSQL".

thanks,
-kt

[Pypgsql-users] Curious Win32 timestamp shift

[Kingsley <kin...@ma...>]

Hi-ho,

I'm using PyPgSQL against a table that has a 'timestamp' type
field.  Under Linux I have no problems, but when results are
returned from the database under win32, they are shifted by +10 hours
(This is also happens to be my timezone.)  I have not applied a
timezone to the timestamp-type field.  Interestingly, they are
being stored correctly, just not retrieved properly.

The times in the database are indeed stored in UTC, but PyPgSQL doesn't 
know this ;)

Any suggestions as to why this should happen only under Windows?
How about hints on how to fix it?

I could always kludge in an:
	timestamp - interval '-36000 seconds'
Type fix, but that's very dodgey.
(even if the timeshift is from time.timezone)

The timezone is set under windows, as it is under Linux.
(GMT+10 / Sydney, NSW)

I'm using "pyPgSQL-pre2.5-20050926.win32-py2.4.exe"
as the latest version crashes my (py2exe) exe, during "import pyPgSQL".

thanks,
-kt

[Pypgsql-users] =?utf-8?b?wqHDmm5ldGUgYSBMYXN0LmZtIQ==?=

[Hector M. M. G. <mi...@gm...>]

 
Hola pyp...@li...,

Agrégame a tus amigos en Last.fm y podremos compartir nuestros gustos musicales :) 
Esta es la música que escucho: http://www.lastfm.es/user/Miuler/?invitedby=Miuler&tp=ff_tp_b

--------


Registrarse es gratis y te llevará menos de un minuto.
Simplemente haz clic para añadirte a mi lista de amigos.
http://www.lastfm.es/join/?invitedby=Miuler&tp=ff_tp_b


Visita mi perfil y déjame una nota, ¡nos vemos!

Hector Miuler Malpica Gallegos




PS: Soy 'Miuler' en Last.fm


--------
Te ha llegado este mensaje porque alguien que conoces (Hector Miuler Malpica Gallegos) te ha enviado una invitación para Last.fm. No hemos guardado tu dirección ni nos pondremos en contacto contigo, a menos que lo desees. 
Encontrarás más información en nuestra política de privacidad: http://www.lastfm.es/help/privacy.php

[Pypgsql-users] PATCH - reference leak in PgConnection

[Andrew M. <an...@ob...>]

This patch, against the CVS HEAD, fixes a reference leak in the
handling of the PgConnection_Type - the cinfo element reference was not
being released in PgConnection_dealloc. The patch also initialises the
PgConnection structure as I don't think you can count on the return from
PyObject_New being zeroed out.

If you would rather, grant my SF account commit privs, and I'll apply
these myself (username "andrewmcnamara").

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

[Pypgsql-users] PATCH - PgVersion_New error handling

[Andrew M. <an...@ob...>]

Attached is a patch against the CVS HEAD that fixes the error handling in
PgVersion_New. The main problems were that NULL returns from pg_strtok_r
were not being handled in many cases, and the early exit path was calling
PyObject_Del (via PgVersion_dealloc), which skips some finalisation that
should occur in Py_DECREF (this mainly effects debug builds of Python).

The patch also deletes the unused pgstricmp function, and uses
PyType_Ready to initialise the type (this is probably not necessary,
as PgVersion_Type isn't a subclass, but it doesn't hurt).

I also considered making PgVersion cyclic GC aware, but there doesn't
appear to be any way it can be involved in a reference cycle.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

Re: [Pypgsql-users] Getting different results for same querry

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

On Sun, 2007-01-07 at 09:35 +0000, dopython python wrote:
> friends i have a problem with my python program accessing postgres
> sql.
> My Postgresql server is installed in debians latest version. My python
> program while accessing the database from two different client
> machines where one machine is  latest debian , with latest
> python-pgsql installed and other machine with old debian sarge and its
> python-pgsql, i am getting  different results for the same query. 
> 
> I am getting correct answer only while i connect from second machine.
> The first machine gives me invalid recordsets also. The SQL querry has
> a condition with a date field between two given dates.
> 
> Please do help me to fix it...
> 
> Regards
> Do Python.

It would be helpful to see the code in question it possible.

[Pypgsql-users] Getting different results for same querry

[dopython p. <dop...@ya...>]

friends i have a problem with my python program accessing postgres sql.
My Postgresql server is installed in debians latest version. My python program while accessing the database from two different client machines where one machine is  latest debian , with latest python-pgsql installed and other machine with old debian sarge and its python-pgsql, i am getting  different results for the same query. 

I am getting correct answer only while i connect from second machine. The first machine gives me invalid recordsets also. The SQL querry has a condition with a date field between two given dates.

Please do help me to fix it...

Regards
Do Python.


 Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php

Re: [Pypgsql-users] pypgsql Win32 build for Python 2.5

[David H. <df...@fo...>]

David Hughes wrote:
> There isn't a pre-built binary for Python 2.5 so I tried building from 
> the source tarball.
>
> libpq-fe.h and other indirectly referenced files are not in the source 
> distribution.
OK, as usual, 10 seconds after posting my brain slipped into gear, and I 
downloaded and found these files in the source distribution of 
postgreSQL itself.

Apologies

David.

[Pypgsql-users] pypgsql Win32 build for Python 2.5

[David H. <df...@fo...>]

There isn't a pre-built binary for Python 2.5 so I tried building from 
the source tarball.

It failed initially because the C compiler didn't find Python.h

building 'pyPgSQL.libpq.libpq' extension
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c 
/nologo /Ox /MD /W3 /GX /DNDEBUG -I -IC:\Python25\include 
-IC:\Python25\PC/Tclibpqmodule.c  
/Fobuild\temp.win32-2.5\Release\libpqmodule.obj
libpqmodule.c
libpqmodule.c(1) : warning C4274: #ident ignored; see documentation for 
#pragma
comment(exestr, 'string')
libpqmodule.c(78) : fatal error C1083: Cannot open include file: 
'Python.h': No such file or directory
error: command '"C:\Program Files\Microsoft Visual Studio .NET 
2003\Vc7\bin\cl.exe"' failed with exit status 2

When I remove the first "-I" parameter it continues a little further but 
then fails to find libpq-fe.h that is referenced in libpqmodule.h

libpqmodule.c
libpqmodule.h(29) : fatal error C1083: Cannot open include file: 
'libpq-fe.h': No such file or directory

libpq-fe.h and other indirectly referenced files are not in the source 
distribution.

What can I do to achieve this build, which is the last step in my 
migration to Python 2.5?

Regards,
David Hughes

Re: [Pypgsql-users] Quoting and UnQuoting strings for Bytea

[Markus S. <ma...@bl...>]

Hello David,

David Hughes wrote:
> PgQuoteBytea:    Escapes a string, which can contain NUL characters, so 
> that it can used as an input to a bytea field.
> PgUnQuoteBytea:    Reverses the action of PgQuoteBytea().

I think this documentation isn't quite right. PgUnQuoteBytea isn't 
exactly the reverse.

> But these don't seem to be completely symmetrical. The quote function 
> also encloses the whole string in single-quotes (why does it need to do 
> this?) and any embedded single-quote characters are escaped as two 
> single-quotes (documented as a security update in pypgsql  2.5) but 
> neither of these are reversed by the unquote function.
> 
> I can work round this by using an construct like:
> 
> sout = PgSQL.libpq.PgUnQuoteBytea(bstring.value).replace("''","'")[1:-1]

Why do you want to do that?

Just use PgQuoteByte() on data you want to send *to* the database. When 
retrieving *from* the database, you get back an escaped string. Use 
PgUnQuoteBytea() to unquote that string and get binary data out of it.

> but I'd like to check, first, if it's really necessary to do this - I 
> may be  doing something  wrong somewhere, and second, is this a safe 
> solution in the general case?

It's only safe as long as the quoting does not change...


Please note, that while the data gets transfered quoted, the database 
saves raw binary data. Quoting is only necessary because pypgsql uses 
the string based protocol.

Regards

Markus

[Pypgsql-users] Quoting and UnQuoting strings for Bytea

[David H. <df...@fo...>]

Hello,

I'm in the process of extending an existing Python application that uses 
pySqlite to use postgreSQL with pypgsql as an alternative dbms (for use 
by up to 50 students simultaneously in a class) and nearly everything is 
working just fine.

I'm using bytea columns to store binary strings that are mainly cPickled 
strings and, in accordance with the pypgsql README I'm using:

PgQuoteBytea:    Escapes a string, which can contain NUL characters, so 
that it can used as an input to a bytea field.
PgUnQuoteBytea:    Reverses the action of PgQuoteBytea().

But these don't seem to be completely symmetrical. The quote function 
also encloses the whole string in single-quotes (why does it need to do 
this?) and any embedded single-quote characters are escaped as two 
single-quotes (documented as a security update in pypgsql  2.5) but 
neither of these are reversed by the unquote function.

I can work round this by using an construct like:

sout = PgSQL.libpq.PgUnQuoteBytea(bstring.value).replace("''","'")[1:-1]

but I'd like to check, first, if it's really necessary to do this - I 
may be  doing something  wrong somewhere, and second, is this a safe 
solution in the general case?

--
Regards,
David Hughes

Re: [Pypgsql-users] [ANNOUNCE] pyPgSQL 2.5 released

[Timothy S. <ti...@op...>]

Gerhard H=E4ring wrote:

>Timothy Smith wrote:
> =20
>
>>Gerhard H=E4ring wrote:
>>   =20
>>
>>>Windows binaries for Python 2.1, 2.2 and 2.3 were uploaded in addition=
=20
>>>to the Python 2.4 binaries.
>>>
>>>     =20
>>>
>>are the windows binaries linked against ssl?
>>   =20
>>
>
>Unlike previous pyPgSQL releases, this one has dynamically linked=20
>binaries. That means they are SSL-enabled if your PostgreSQL client=20
>library installation (libpq.dll) is.
>
>-- Gerhard
>
>
>
>_______________________________________________
>Pypgsql-users mailing list
>Pyp...@li...
>https://lists.sourceforge.net/lists/listinfo/pypgsql-users
>
>
> =20
>
if anyone has a copy of libpq.dll with ssl enabled for windows that=20
works with 2.5.1 could they please link me to it.

Re: [Pypgsql-users] Savepoint or subtransaction support

[Markus S. <ma...@bl...>]

Hi,

Clarence Gardner wrote:
> Actually, PostgreSQL is following the SQL standard in that respect. 
> Given that, I think your patch has an error when it's searching for the 
> savepoint name to rollback to. In case the same name is currently active 
> more than once, you want to search from the end of your list of 
> savepoint names rather than from the beginning (since savepoint() 
> appends to the list).

Good catch! I didn't think about that. Can we use rindex() or do we have 
to support python <= 2.3? What's the best way to do it for python 2.3? 
Does somebody know a more elegant solution than:

a = [...]
a.reverse()
idx = len(a) - a.index(..) - 1
a.reverse()

>> (I've tried to upload the page to the 'patches' page on SourceForge, 
>> but didn't succeed, I've only added a useless comment, sorry. Please 
>> bear with a SF-first-timer.)
>>
> I had what may be the same problem. Even if you set the file to upload, 
> the server ignores it unless you check the checkbox labeled "Upload 
> file" (or something).

Hm... I didn't even get to an 'upload file' dialog. I thought that would 
show up when confirming your comment. But despite all the other 
'confirm' buttons you have to click when subscribing, your comment gets 
added instantly.

Anyway, I now suppose I have to be a member of the project to add 
patches? Or how do I do that?

Regards

Markus

Re: [Pypgsql-users] Savepoint or subtransaction support

[Clarence G. <cla...@ad...>]

Hi, Markus. Thanks for expanding upon my patch, which was very minimal 
(=lazy) and
pretty much did just what I needed. Although since apparently nobody 
ever used savepoints
while using pypgsql (which we know because if you tried to use them 
yourself, the library would get in the way), I didn't feel *too* bad 
about it.

> I've modified my patch to support multiple savepoints. I'm now using 
> the same methods as the original patch (i.e. savepoint, release and 
> rollback)
>
> The original patch from [1] did release a savepoint if it already 
> existed. I think that's dangerous. In fact, PostgreSQL even allows to 
> define multiple savepoints with the very same name.
Actually, PostgreSQL is following the SQL standard in that respect. 
Given that, I think your patch has an error when it's searching for the 
savepoint name to rollback to. In case the same name is currently active 
more than once, you want to search from the end of your list of 
savepoint names rather than from the beginning (since savepoint() 
appends to the list).
>
> (I've tried to upload the page to the 'patches' page on SourceForge, 
> but didn't succeed, I've only added a useless comment, sorry. Please 
> bear with a SF-first-timer.)
>
I had what may be the same problem. Even if you set the file to upload, 
the server ignores it unless you check the checkbox labeled "Upload 
file" (or something).

Re: [Pypgsql-users] Savepoint or subtransaction support

[Markus S. <ma...@bl...>]

Hi,

Our patches were very similar, I like the single rollback() method with 
added support for savepoints. Adding a rollback_savepoint method (as I 
did) is not that elegant.

I've modified my patch to support multiple savepoints. I'm now using the 
same methods as the original patch (i.e. savepoint, release and rollback)

The original patch from [1] did release a savepoint if it already 
existed. I think that's dangerous. In fact, PostgreSQL even allows to 
define multiple savepoints with the very same name.

Also, if you rollback to a savepoint, the savepoint is not released. So 
you can rollback to a savepoint several times. This also allows you to 
call rollback() and then release() on the same savepoint.

If you define multiple savepoints A, B, C (in that order), rolling back 
to savepoint A obviously releases the savepoints B and C. My patch takes 
that into accont. Please note that savepoint A still remains and does 
not get released when rolling back to it.

(I've tried to upload the page to the 'patches' page on SourceForge, but 
didn't succeed, I've only added a useless comment, sorry. Please bear 
with a SF-first-timer.)

Regards

Markus

[1]: the original patch:
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1511984&group_id=16528

Markus Schiltknecht wrote:
> Hi,
> 
> as I really urgently need savepoints, I have written a small patch to 
> add support for one savepoint. Only to find out that I should have 
> looked in the SF 'patches' page where someone else did exactly the same...
> 
> I'm comparing our patches just now.
> 
> Regards
> 
> Markus

Re: [Pypgsql-users] Savepoint or subtransaction support

[Markus S. <ma...@bl...>]

Hi,

as I really urgently need savepoints, I have written a small patch to 
add support for one savepoint. Only to find out that I should have 
looked in the SF 'patches' page where someone else did exactly the same...

I'm comparing our patches just now.

Regards

Markus

Markus Schiltknecht wrote:
> Hi,
> 
> I'd like to use savepoints or subtransactions. Now PyPgSQL does not seem 
> to support them.
> 
> Searching through the archives brought up a bug [1] and a feature 
> request at [2] for savepoint support. Another guy run into the same 
> problem as I did, but his solution seems dubious, see [3].
> 
> What's PyPgSQL's state concerning subtransactions or savepoints? What 
> does the Python DB-API say about them? What do other (i.e. MySQL 
> interfaces) do?
> 
> Regards
> 
> Markus
> 
> 
> [1]: Bug:
> https://sourceforge.net/tracker/index.php?func=detail&aid=1409818&group_id=16528&atid=116528
> 
> [2]: Feature Request:
> https://sourceforge.net/tracker/index.php?func=detail&aid=1503756&group_id=16528&atid=366528
> 
> [3]: Don't use transactions
> https://sourceforge.net/tracker/index.php?func=detail&aid=1524586&group_id=16528&atid=116528
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Pypgsql-users mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypgsql-users

[Pypgsql-users] Savepoint or subtransaction support

[Markus S. <ma...@bl...>]

Hi,

I'd like to use savepoints or subtransactions. Now PyPgSQL does not seem 
to support them.

Searching through the archives brought up a bug [1] and a feature 
request at [2] for savepoint support. Another guy run into the same 
problem as I did, but his solution seems dubious, see [3].

What's PyPgSQL's state concerning subtransactions or savepoints? What 
does the Python DB-API say about them? What do other (i.e. MySQL 
interfaces) do?

Regards

Markus


[1]: Bug:
https://sourceforge.net/tracker/index.php?func=detail&aid=1409818&group_id=16528&atid=116528

[2]: Feature Request:
https://sourceforge.net/tracker/index.php?func=detail&aid=1503756&group_id=16528&atid=366528

[3]: Don't use transactions
https://sourceforge.net/tracker/index.php?func=detail&aid=1524586&group_id=16528&atid=116528

[Pypgsql-users] Problems with pyPgSQL 2.5.1 with open SUSE 10.0

[IT-Support @ A. TU D. <it-...@as...>]

Hello,

I have a SUSE 10.0 Installation with pyPgSQL 2.5.1 installed from an
rpm-file.

When I start a script for a software-installation I get the following error:

buero2:/tmp/lx-kasse/erpkasse # ./erpkonfig -new
You need to install pyPgSQL
Traceback (most recent call last):
File "erpkonfig.py", line 18, in <module>
NameError: name 'sys' is not defined

So, pyPgSQL can't be found by the script - what can I do?

Thanks!

Ivan

[Pypgsql-users] why does this bytea import fail when locale is activated ?

[Karsten H. <Kar...@gm...>]

The attached script fails when the locale is activated (at
the top) and succeeds when it is commented out.

Can someone please explain why ?

I am out of my wits.

Thanks
Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Re: [Pypgsql-users] possible problem with unicode_results = 1

[Karsten H. <Kar...@gm...>]

Sorry, forget the post below. I was totally blind.

Sorry,
Karsten

On Tue, Aug 29, 2006 at 01:37:10PM +0200, Karsten Hilbert wrote:
> User-Agent: Mutt/1.5.13 (2006-08-11)
> Subject: [Pypgsql-users] possible problem with unicode_results = 1
> 
> Hello community,
> 
> I am not sure I understand how unicode_results is supposed
> to work right:
> 
> Assume this:
> 
> - client_encoding is set to 'iso8859-1' at the connect() level
> - hence "set client_encoding" must also be set to 'iso8859-1' at the SQL level
> - thereby, strings *returning* from the database are encoded
>   as 'iso8859-1', too, when they enter pyPgSQL from libpq
> 
> - now I want to have results in unicode
> - hence I set unicode_results=1 at the connect() level
> - thereby string-types are passed to unicode() in pyPgSQL
>   without further arguments as per the code
> - hence unicode() uses the default encoding as per Python docs
> - which in most cases is "ascii"
> - bad things happen
> 
> Really, the client_encoding value should be passed in to
> unicode() as well, shouldn't it ?
> 
> Or is my logic flawed ?
> 
> No, it is not always possible to set the Python default
> string encoding to something sane as would seem prudent to
> do. It is not recommended to do so, either.
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Pypgsql-users mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypgsql-users
> 

-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

[Pypgsql-users] possible problem with unicode_results = 1

[Karsten H. <Kar...@gm...>]

Hello community,

I am not sure I understand how unicode_results is supposed
to work right:

Assume this:

- client_encoding is set to 'iso8859-1' at the connect() level
- hence "set client_encoding" must also be set to 'iso8859-1' at the SQL level
- thereby, strings *returning* from the database are encoded
  as 'iso8859-1', too, when they enter pyPgSQL from libpq

- now I want to have results in unicode
- hence I set unicode_results=1 at the connect() level
- thereby string-types are passed to unicode() in pyPgSQL
  without further arguments as per the code
- hence unicode() uses the default encoding as per Python docs
- which in most cases is "ascii"
- bad things happen

Really, the client_encoding value should be passed in to
unicode() as well, shouldn't it ?

Or is my logic flawed ?

No, it is not always possible to set the Python default
string encoding to something sane as would seem prudent to
do. It is not recommended to do so, either.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Re: [Pypgsql-users] coding question

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mignon Laurent wrote:
> Hy,
> 
> In your python abstraction layer (pgsql.py) you directly access the
> __dict__ .  If I understand the code, you use this mechanism in
> conjunction of the overriding of __setattr__ to control the acces to
> some attributes that you want  readonly. 
> I can understand that that was in the past the only way to control
> access to some attributes. Today, python allow you to define property
> and to control access to a variable through getter and setter ...
> The fact that the code access direclyt to the __dict__ is a problem for
> me when I use this module in threads running in restricted mode (access
> is denied!).  Can I rewrite the code to use property and avoid the
> access to the __dict__. Do you think that it is a good thing?

You can of course rewrite the code yourself for your own uses. The reason
pyPgSQL uses tricks with __dict__ is that it was written with Python 2.1
compatibility in mind.

If the code was written today, it would of course be written using modern
Python features :-)

- -- Gerhard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE5jdUdIO4ozGCH14RAnUvAKCOjGttmaZ0aR/R44VUCmt/iZvmDwCeO2vk
hnuM0hXIF+/72MLWdjUYuhE=
=LynY
-----END PGP SIGNATURE-----

[Pypgsql-users] coding question

[Mignon L. <mig...@ya...>]

Hy,

In your python abstraction layer (pgsql.py) you directly access the __dict__ .  If I understand the code, you use this mechanism in conjunction of the overriding of __setattr__ to control the acces to some attributes that you want  readonly.  
I can understand that that was in the past the only way to control access to some attributes. Today, python allow you to define property and to control access to a variable through getter and setter ... 
The fact that the code access direclyt to the __dict__ is a problem for me when I use this module in threads running in restricted mode (access is denied!).  Can I rewrite the code to use property and avoid the access to the __dict__. Do you think that it is a good thing? 

Laurent Mignon

Software AG Belgium
Senior Software Engineer
 
 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Pypgsql-users] Using pyPgSQL on Mac OS X Tiger

[<at...@ko...>]

I downloaded and built the package on Mac OS X 10.4 via "python
setup.py build".
Then I installed it with "python setup.py install"
"import pyPgSQL" works, but "from pyPgSQL import PgSQL" brings up an
error message.
It sais: "ImportError: No module named libpq"

The folderstructure in site-packages looks like this:
./pyPgSQL/
./pyPgSQL/__init__.py
./pyPgSQL/__init__.pyc
./pyPgSQL/PgSQL.py
./pyPgSQL/PgSQL.pyc
./pyPgSQL//libpq/
./pyPgSQL//libpq/__init__.py
./pyPgSQL//libpq/__init__.pyc
./pyPgSQL//libpq/libpqmodule.so

I also renamed the module twice, first in the file system and then in
setup.py.
so the last file looked like this:
./pyPgSQL//libpq/libpq.so
Still the same Error.
Does anyone know of a solution?
Regards,
atillla