Am 26.11.2015 um 16:24 schrieb D'Arcy J.M. Cain:
> New Sphinx documentation.
> Note - not finished yet. Committed to allow others to work on it.
Would be great to move the docs to Sphinx. It's also supported by
readthedocs.org - would be nice to have the docs up there. Everything
can be
Am 26.11.2015 um 18:44 schrieb D'Arcy J.M. Cain:
Are you thinking that it would be enabled by default in 5.0 or wait
until 6.0?
I'm still following the idea that we should leave 5.0 more or less
backward compatible to 4.x. The big new feature is Python 3 support, and
more features are added,
Am 25.11.2015 um 15:19 schrieb D'Arcy J.M. Cain:
> FYI, the money type was written by me based on a chapter that I wrote
> for a book called "Software Solutions in C'. That was back in the old
> days when programmers actually cared about processing time. :-)
I still remember the days, wrote a
Am 25.11.2015 um 20:34 schrieb D'Arcy J.M. Cain:
> Perhaps you haven't backported everything yet. I am sure that I saw
> fixes for some of this at least.
You probably need to recompile, the backporting also changed C code.
-- Christoph
___
PyGreSQL
Am 25.11.2015 um 20:44 schrieb D'Arcy J.M. Cain:
I was looking in the docs directory and I see some files that have both
a .txt and a .rst version. I think that the .rst versions were
supposed to be removed. Anyone remember?
I'm not sure. The buildhtml script looks only for the txt versions
Am 25.11.2015 um 07:40 schrieb Philipp Hahn:
What about a unicode character where the second or third octet falls
into the '0' to '9' range? It seems to me that we really need unicode
versions of ctype functions.
Will not happen: All subsequent bytes of UNICODE characters encoded in
UTF-8
Am 24.11.2015 um 21:52 schrieb Patrick TJ McPhee:
I've attached a patch which adds test_notify_twice() to demonstrate the
problem and puts getnotify() et al in a loop to address it.
Thanks, that was a nice catch and contribution. I've refactored the code
to make the loops a bit simpler and
Am 24.11.2015 um 17:38 schrieb D'Arcy J.M. Cain:
> It no longer segfaults. I am not sure that you needed to make such a
> drastic fix though. Did you consider casting to unsigned int? I
> suspect that the problem was chars > 127 being converted to negative
> numbers. The only negative number
Am 24.11.2015 um 17:38 schrieb D'Arcy J.M. Cain:
> It no longer segfaults. I am not sure that you needed to make such a
> drastic fix though.
Btw, that check-in contained some more tests. The fix itself was not
drastic it all: There were only two similar places where isdigit() was
used when
Am 24.11.2015 um 04:57 schrieb D'Arcy J.M. Cain:
> Same failure under 2 and same segfault under 3.
>
> It segfaults in testSetDecimalPoint, the same test that has the error
> in Python 2.
Can you try again (see my last commit message about NetBSD)? Don't
forget to recompile and reinstall the C
Am 23.11.2015 um 11:42 schrieb D'Arcy J.M. Cain:
Right. I have actually started updating my production databases but
not my test one. I could easily drop and recreate it but first we
should decide if it should work with ASCII databases. Many people will
still have them. Are we going to
Am 23.11.2015 um 11:42 schrieb D'Arcy J.M. Cain:
> Right. I have actually started updating my production databases but
> not my test one. I could easily drop and recreate it but first we
> should decide if it should work with ASCII databases.
Definitely, at least the things that you can
Am 23.11.2015 um 21:20 schrieb D'Arcy J.M. Cain:
It's fine under Xubuntu but under NetBSD I am still having the same
issue. Same three errors under Python 2 and segfault under Python 3.
Ok, two of the three errors are subsequent faults probably caused by the
decimal point not being reset
I'm just opening a bottle of beer because now all tests are running for
me under both Python 2 and 3, on two different Linux systems with
different versions and one Windows system with Py 3.5 and Pg 9.4.
Of course this needs some more rigid testing before it can be released.
But I think we
Am 20.11.2015 um 18:08 schrieb D'Arcy J.M. Cain:
I am still having errors in my 2.7 installation on the 4.x branch. It
seems that something between the database and the query result is
converting small ints (and any ints) to long. Are you not seeing that?
I am using PostgreSQL 9.3.5 and
Am 20.11.2015 um 20:16 schrieb D'Arcy J.M. Cain:
I agree with your reasons. The only thing is that the tests are
going to need to be changed based on the version of Python as well.
There is probably going to be an awful lot of places to introduce
conditional code in the tests.
The good thing
Am 18.11.2015 um 19:04 schrieb D'Arcy J.M. Cain:
> I found errors in the TEST_PyGreSQL_classic_connection.py run. The
> diff at the bottom of this message fixed some of them but I am not
> sure if they should be committed. In any case I don't want to bump
> into your work so I will leave you to
Am 18.11.2015 um 19:36 schrieb D'Arcy J.M. Cain:
> Right. I forgot to run the install. Now I am down to just one error
> in that test.
Ok, I fixed that last problem by setting utf8 encoding. Your test
database probably had a different one.
-- Christoph
Am 18.11.2015 um 20:06 schrieb D'Arcy J.M. Cain:
You're right. I guess we also need to test the port against -1. And
that alerted me to this strange bit of code:
self.assertEqual(self.connection.port, dbport or dbport)
I'm
Am 18.11.2015 um 20:00 schrieb D'Arcy J.M. Cain:
So do we only support UTF8 databases then? I certainly ran for years
on ASCII databases.
No, of course not. The test just assumed the client encoding was set to
utf8 and I didn't notice is because my test database was set to utf8.
Here in
Am 17.11.2015 um 21:13 schrieb D'Arcy J.M. Cain:
Are we testing the reconnect function? I was considering making the
tests run twice with the second time connecting with an existing DB
object. Might be overkill though.
You mean reopen() and reset()? They are tested, but not very thoroughly.
Am 15.08.2015 um 16:15 schrieb D'Arcy J.M. Cain:
I am running the latest version, 0.7. What was the error message?
Same as mentioned in the Trac ticket IndexError: pop from empty list.
However, just noticed the ticket mentions a workaround: After changing
the language to English in the
Another recommendation would be to use SQLAlchemy instead of directly
working with DBAPI2. I'm pretty sure SQLAlchemy works with Jython, and
it has a dialect for pg8000.
-- Christoph
___
PyGreSQL mailing list
PyGreSQL@vex.net
Don't worry, the PyGreSQL list is not such a crowded audience ;)
If nobody jumps in, I can at least put your contribution in our Trac so
that it won't get lost. I will have more time later this year and hope
to work on PyGreSQL and push it forward again - so we can have 4.2 and
5.x versions
Am 22.04.2015 um 15:11 schrieb da...@pygresql.org:
-for n, t in attnames.iteritems():
+for n, t in attnames.items():
Hm, I would rather use 2to3 to translate such expressions to Python 3.
Always creating a list in Python 2 is not so good.
-- Chris
Thanks for the contribution, Brad. I have planned to work on PyGres
again this year (Py 3 version is one of the goals) and made a note to
review your submission.
-- Christoph
___
PyGreSQL mailing list
PyGreSQL@vex.net
Am 29.10.2013 05:58, schrieb raf:
this happens when trying to install any python package
that requires compilation but it used to work fine on
windows 7 and below using gcc from cygwin.
Not sure about cygwin, but you can definitely use MinGW.
i assume i'll need Visual Studio Express 2013 for
Am 05.03.2013 14:14, schrieb D'Arcy J.M. Cain:
On Tue, 5 Mar 2013 13:24:09 +0100
Anja Skrba an...@webhostinggeeks.com wrote:
It would be placed here: http://science.webhostinggeeks.com/
As soon as I finish the translation I will send it to you, so you can
review it.
Of course, I will include a
Am 05.03.2013 15:50, schrieb D'Arcy J.M. Cain:
It is? I checked out the page and I didn't see any obvious issues. Of
course, I can't read Serbo-Croatian but I didn't see any ads that
weren't in the original pages other than a reference to themselves as
the translator which I think we would
Am 03.02.2013 13:33, schrieb alexandra:
I'm trying to upgrade to python2.7.
Installed PyGresql 4.1.1 for python 2.7.
When running import pg command I get the following error:
from _pg import *
ImportError: DLL load failed: The operating system cannot run %1.
I'm using Windows XP SP3, and have
Am 03.02.2013 15:02, schrieb Christoph Zwerschke:
I'll upload additional binaries for Postgres 8 compiled with
escaping_funcs=0 today.
@D'Arcy: Can you copy the new files from
~cito/files/PyGreSQL-4.1.1.*-pg8.4.*
to the public download foloder?
I also made them available on PyPi now:
http
Am 07.01.2013 03:36, schrieb D'Arcy J.M. Cain:
What about PyGreSQL.spec? It seems to be way out of date and unused.
Should we just delete it?
As you can see from the diffs I plan to release 4.1.1 on Tuesday. The
beta is in the usual place if anyone wants to preview it.
I think the .spec
Am 06.01.2013 00:43, schrieb D'Arcy J.M. Cain:
I just ran the updated unit tests against the 4.1 version and it
failed to fail other than missing pgnotify and one of the quote
tests. What update or insert test is testing the problem with 4.1?
It should fail with 4.1, and it does for me. The
Am 06.01.2013 15:14, schrieb D'Arcy J.M. Cain:
The pgnotify method is a new feature so should we call it 4.1.1 or
4.2?
Better 4.1.1 to make it clear that it's a bugfix release. This also
gives us some time to let pgnotify mature until we officially announce
and document it in 4.2. We also
As you already noticed, I have refactored and cleaned up pgnotify and
the corresponding tests a bit. They run also much faster now. The code
is still pretty much compatible to the original pgnotify, and still uses
the same name. One thing I added besides the payload bit is a
listening
As you noticed, when using the same database connection for the handler
and notification, problems can appear because two different threads are
now using the same connection. This is also the case if you use the
notify() method from outside, since it uses the same connection.
I have solved
Am 04.01.2013 23:10, schrieb Christoph Zwerschke:
Our unit tests for update() and insert() obviously were not
exhaustive enough so it was a bad idea to rely on these.
Just looked into this. We have tests for update and insert, but the
problem with these is that update and insert reload
Am 04.01.2013 17:47, schrieb Patrick TJ McPhee:
I just had an inconsistency in db.insert and db.update brought to my
attention. Previous versions of pygresql accepted the various date literals
(current_timestamp et al) as values in db.insert() and db.update().
I've looked into this now and I
Am 05.01.2013 16:47, schrieb D'Arcy J.M. Cain:
On Sat, 5 Jan 2013 10:07:58 -0500 (EST)
da...@pygresql.org wrote:
Handle money results properly when decimal point is a','.
I didn't see the unit test changes. I assume that they are tied up
with your insert/update changes and you are holding
Am 05.01.2013 19:41, schrieb D'Arcy J.M. Cain:
We could always make C locale the default and have a setting for
others. Let the user control it. In any case the user should always
strip out the thousands separator if there is any possibility of
confusion.
The setting already exists, it is
Am 05.01.2013 17:25, schrieb Christoph Zwerschke:
Am 05.01.2013 16:47, schrieb D'Arcy J.M. Cain:
finished. What about this?
123,456
Postgres would not create such an output, it would create $123,456.00 or
123.456,00 €. Except maybe when you have a locale where frag_digits =
0 (i.e
Am 03.01.2013 04:46, schrieb D'Arcy J.M. Cain:
OK, I went to tag and bag and I don't see how. Do we just record the
current version number somewhere? What did we do last time?
In Subversion, you just do a copy to create tags. Something like this:
svn copy
Am 03.01.2013 13:56, schrieb D'Arcy J.M. Cain:
Should it be called branches/4.x since it will be the the trunk for
the 4.x series?
Right, tags/4.1 and branches/4.x would be more clear.
-- Chris
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
Am 01.01.2013 14:09, schrieb D'Arcy J.M. Cain:
I never did find time for this and today is supposed to be the release
date. Do you think I should push the release out the door or wait
until we finish off the web site?
I would say push it out, and add Trac tickets for the remaining issues.
--
Just noticed some problems when trying to create binaries for Windows
for 4.1 using Visual Studio. Compiling with MinGW works, but I need to
make some changes to make it work with Visual Studio as well. If you
haven't created a tag and announced the release, I'd like to sneak these
changes in
Am 03.12.2012 19:14, schrieb D'Arcy J.M. Cain:
I have a sample. It is the basic Sphinx theme with a few colour
changes. More than that will involve layout changes and stylesheet
changes. If anyone has any suggestions I don't mind doing more before
committing it.
Am 04.12.2012 15:11, schrieb D'Arcy J.M. Cain:
OK. I did increase them because I thought that they were too small
but I am no designer. How about now?
Much better. Maybe even too small already.
http://packages.python.org/cloud_sptheme/cloud_theme.html
Am 31.10.2012 15:01, schrieb D'Arcy J.M. Cain:
We also have ticket #20 that needs Py 2.5 and was originally planned
for 4.2. It would be nice to get that into 4.1 already then.
Go for it.
Ok, so I've started thinking how to make use of context managers in
PyGreSQL. For pgdb, it's pretty
Am 31.10.2012 02:50, schrieb D'Arcy J.M. Cain:
I put Dec 1 but I have no problem pushing to the new year if need be.
Ok, let's say Dec 1 then. We really need to get that out. I have adapted
the milestones already.
-- Christoph
___
PyGreSQL mailing
The last version officially supported Py 2.3-2.6 and Pg 7.4-8.4. I saw
you changed that to Py 2.5-2.7 and Pg 8.3-9.2 for v4.1.
But there are still many places which make provisions for earlier
versions, and the checks and docstring in setup.py also still have the
old version ranges. I want to
Am 31.10.2012 15:01, schrieb D'Arcy J.M. Cain: We don't actually have a
way of testing against the matrix of all
supported versions. Any ideas about that?
I think it would be sufficient to test only the diagonale of the matrix,
e.g. Py2.5/Pg8.3, Py2.6/Pg9.0, Py2.7/Pg9.2. Travis CI would be
Hi D'Arcy, I saw you're trying to release 4.1, which is great because it
has been long overdue. There are currently 7 issues still open:
http://trac.vex.net:8000/pgtracker/milestone/4.1
You can move them forward to the next release, but please let me look at
least at #25 and #47 before making
Am 01.10.2012 21:54, schrieb Christoph Zwerschke:
Am 01.10.2012 15:33, schrieb Patrick TJ McPhee:
I've attached a patch against SVN head that implements positional
parameters in the classic API's query method.
Sounds great. I'll look into it this and give feedback later.
Thanks a lot
Am 26.09.2012 16:05, schrieb Patrick TJ McPhee:
I guess the idea here is to cycle on calls to PQexecParams() until we're out
of arguments.
Right. PQexecParams() can only execute one command at a time. Btw,
that's different from PQExec(), so in order to stay backward compatible,
I think we
Am 25.09.2012 19:19, schrieb Nico Latzer:
to me this is definitively a good step forward. please allow me to
share a feeling, it might be more cleaner design to handover the
arguments packed as a tuple.
Agree. This would also allow passing a list of tuples in which case
multiple queries
Am 21.09.2012 21:48, schrieb Patrick TJ McPhee:
I've made a change which allows queries to be made like this, using the
classic interface:
db.query(insert into x (a,b,c) values ($3,$1,$2), 'bravo', 3, 'alpha')
db.query(select * from x where a = $1, 'alpha')
I think that's a good idea. I guess
Am 17.09.2012 07:21, schrieb raf:
it seems that pygresql is expecting the old ssl library version.
No, pygresql itself doesn't expect anything, it just uses whatever libpq
it finds. The libpq then references libssl, and in your setup the new
libpq finds only the old libssl, so there's
Am 30.10.2011 17:27, schrieb Kristen Eisenberg:
I'm developing a web application using Pygresql, and it's been sort of
misbehaving recently.
Please ignore. That's an exact copy of an older post that has already
been answered and obviously his only purpose was to spread the spam URL
added at
Am 07.05.2012 09:50, schrieb Peter Harris:
Yes, it is better as an attribute of the exception, since I agree it
is not much use until an error occurs. I wasn't sure how to add an
attribute to the exception class, so I put it on the connection
because it was simpler :)
Ok, I've now implemented
Peter, I'm just reviewing your SQLSTATE patch.
It works nicely with both the classic API and the DB-API 2.
But I wonder whether making it a property of the connection is the right
approach.
In DB-API 2 we could make it a property of the cursor instead, and
instead of storing the last
Thanks. I'll look into your patches this week.
-- Christoph
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo.cgi/pygresql
Am 26.04.2012 23:35, schrieb D'Arcy Cain:
(http://www.pygresql.org/viewvc.cgi/pygresql/) and Trac
(http://trac.vex.net:8000/pgtracker) didn't work.
D'Arcy, can you have a look? What's the lastest status here?
Fixed. I also passed both URLs to my wife to add to her daily
testing of web sites.
Am 27.04.2012 00:18, schrieb Christoph Zwerschke:
Trac works now, but the SVN viewer still doesn't work (only the source
viewer included in Trac) and I still can't checkout from SVN.
Ah, sorry, just noticed you changed the URL to
http://shell.Vex.Net/viewvc/pygresql which works.
-- Christoph
Am 27.04.2012 00:21, schrieb Christoph Zwerschke:
Ah, sorry, just noticed you changed the URL to
http://shell.Vex.Net/viewvc/pygresql which works.
I meant http://shell.vex.net/viewvc.cgi/pygresql/
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https
Am 02.12.2011 16:58, schrieb D'Arcy Cain - PyGreSQL:
We fell behind even more. The system that PyGreSQL was developed on was
hacked and I am just now getting the last items restored. The system is
now built properly and security patches are being applied as soon as
they are available.
Am 30.10.2011 17:27, schrieb Kristen Eisenberg:
I'm developing a web application using Pygresql, and it's been sort of
misbehaving recently.
Which versions of Pygres and Postgres are you using?
-- Christoph
___
PyGreSQL mailing list
PyGreSQL@vex.net
Am 26.10.2011 20:59, schrieb Aleksey Tsalolikhin:
What's the development roadmap for PyGreSQL, please? I am especially
interested in support for PostgreSQL 9.x
Here it is: http://trac.vex.net:8000/pgtracker/roadmap
Unfortunately, we fell back behind our plan again. I was just too busy
with
Am 25.10.2011 02:58, schrieb Aleksey Tsalolikhin:
Our python program does have multiple threads, but each thread is supposed
to set up its own connection to Postgres.
If that's the case, PyGres should work fine for you. Also, your program
seems to hang where Python is acquiring a lock, but
Am 16.08.2011 20:43 schrieb Chris:
Hello...do you have a link to the 'cleaned-up' setup.py ? And do you have
directions on the two issues you discovered? Can I be of help in working on any
of this for you?
I am running 64-bit Python 2.7 (with PIL, psycoPG) and 64-bit PostgreSQL 9.0 on
a
Am 17.07.2011 22:47 schrieb D'Arcy J.M. Cain:
On Sun, 17 Jul 2011 21:39:12 +0200
Christoph Zwerschkec...@online.de wrote:
The 4.x branch is our backward compatible maintenance branch, therefore
we shouldn't push ahead so quickly here, but maybe require Py 2.4 in 4.1
and Py 2.5 in 4.2?
OK.
Am 16.07.2011 18:59 schrieb Maxim Yegorushkin:
+elif isinstance(val, float):
+if math.isnan(val):
+val = 'NaN'
+elif math.isinf(val):
+val = 'Infinity' if val 0 else '-Infinity'
elif val is None:
val =
Am 06.07.2011 01:46, schrieb Tom Lane:
If you want bug reports submitted that way, the README file ought
to point people to it, instead of to this mailing list ...
Right, Trac should be mentioned there and have a link on the homepage.
-- Christoph
Am 05.07.2011 22:15 schrieb Tom Lane:
I received a report that set_decimal() doesn't work as expected in
PyGreSQL 4.0:
https://bugzilla.redhat.com/show_bug.cgi?id=719093
I will look at this and some other open issues this weekend.
But I wonder what happened to our trac that used to be here:
Hi Mark,
Is it possible that pygresql doesn't know how to handle the arrays
properly?
That's true, Postgres arrays have never been supported by Pygres,
probably because they were pretty restricted anyway so hardly anybody
was using them (maybe they have become more useful in newer Postgres
Am 02.09.2010 23:59 schrieb Glyph Lefkowitz:
If I can submit a patch before that infrastructure is available (I
know how these types of projects can recede into the infinite future)
is there a good chance that it might be accepted?
If it's not too complex, sure. But getting our Trac online
Am 30.08.2010 00:11 schrieb Glyph Lefkowitz:
Personally my preference would be to actually have a separate exception
class for each error code, so that I could do 'except
pg.errors.UniqueViolation:', but that is probably a bunch more work than
simply adding an integer attribute.
Hi Glyph,
Am 06.08.2010 10:12 schrieb Chris Danek:
First (and possibly the easiest solution) - is there a win64 binary
distribution that someone's built? http://www.pygresql.org/readme.html
only has win32 binaries, which don't seem to read the registry
properly for the location of the python installation
Am 11.07.2010 18:49 schrieb D'Arcy J.M. Cain:
This is up. I had asked if we should put the Trac site on the web page
but didn't see any response.
Really? The URLs that I had currently do not work, nor does the SVN
checkout address. Did you relocate them again? And yes, there should be
links
Am 11.07.2010 21:06 schrieb Martin v. Löwis:
My recommendation would be to support 3.x in the current code base.
If done correctly, there shouldn't be any significant for 2.x users.
If I understand correctly, you're recommending the first approach then,
using 2to3 (use_2to3=True in the setup
Am 11.07.2010 20:58 schrieb D'Arcy J.M. Cain:
It is still http://trac.pygresql.org:8000/trac. Problem was that I had
to change the name of the PyGreSQL user as it conflicted with the
mailing list and I forgot to restart the trac server. Check it now.
As for SVN, the URI on the page works for
Am 11.07.2010 23:03 schrieb D'Arcy J.M. Cain:
I have the SVN URI in trac.conf. Is there something else that needs to
be done?
Some of the needed plugins have not been enabled. I've done that via the
admin interface now, the Browse Source button appears, but the SVN path
seems to be wrong.
Am 28.03.2010 22:15 schrieb Steven Norris:
I have the path [PostgreSQL]\libpq64 in my environment variables as:
C:\Program Files\PostgreSQL\libpq64 but I am still getting the
same error.
Are you sure? The error message looks like only the 32bit dll was found,
not the 64bit dll. If both are
Am 27.03.2010 17:33 schrieb Steven Norris:
I used the 64 bit install of PygreSQL and have [postgres]/bin and
[postgres]/lib in my System Path, but I can't seem to find the
libpq64.dll. I know for a fact that this is the 64 bit version of
postgres though. Should it not have come pre-installed
At http://archives.postgresql.org/pgsql-hackers/2010-02/msg00351.php
folks are complaining about the confusing mess of PostgreSQL drivers for
Python and that there is not one terrific driver to rule them all.
In fact, there are a couple of drivers that have evolved over the years,
each with
Am 07.02.2010 15:43 schrieb D'Arcy J.M. Cain:
Lord of the DB-APIs? :-)
Maybe Dark Lord Sauron is already forging the evil OgresQL API ;-)
Does one ot the other need to be the focus? One thing that I have
wanted to do for a while is make the classic interface a pure Python
wrapper around
Am 04.02.2010 22:57 schrieb Ma Chenwei:
I have a few daemons written in python, which access a postgres
database constantly. As I was hunting for leaks I found what the way I
create and close the database connection is creating some leaks. I got
it down to a test loop to demonstrate the problem:
Maybe on the commandline you have a different PATH than when running
your Python script? Otherwise I'm running out of ideas.
You can try to compile PyGreSQL yourself using the header files of your
Postgres version, but you will need MinGW or Visual Studio for that.
-- Christoph
Am 07.01.2010 09:18, schrieb Saeed Bhuta:
File /usr/lib/python2.6/decimal.py, line 3640, in __init__
setattr(self, name, _copy.copy(getattr(DefaultContext, name)))
AttributeError: 'module' object has no attribute 'copy*'
Maybe you have a module named copy somewhere in your path that is
Update of /usr/cvs/Public/pygresql/docs
In directory druid.net:/tmp/cvs-serv16211
Modified Files:
changelog.txt
Log Message:
One major change was missing in the changelog for version 4.0.
To see the diffs for this commit:
Update of /usr/cvs/Public/pygresql/docs
In directory druid.net:/tmp/cvs-serv3551/docs
Modified Files:
changelog.txt
Log Message:
Escape and unescape Binary objects (as suggested by Dan McDonald).
To see the diffs for this commit:
Update of /usr/cvs/Public/pygresql/module
In directory druid.net:/tmp/cvs-serv3551/module
Modified Files:
TEST_PyGreSQL_dbapi20.py dbapi20.py pgdb.py
Log Message:
Escape and unescape Binary objects (as suggested by Dan McDonald).
To see the diffs for this commit:
Tim Callaghan schrieb:
I'm using the DB wrapper class of the classic postgres interface (pg), I
don't see anything in the documentation regarding how to implement
transactions (commit/rollback). Am I missing something?
You must use query('commit') and query('rollback') here.
-- Christoph
Tim Callaghan schrieb:
So I'd start with a query('begin') to start my transaction?
Yes, if you *want* a transaction. Otherwise Postgres will auto commit
for you after every command.
-- Christoph
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
Update of /usr/cvs/Public/pygresql/docs
In directory druid.net:/tmp/cvs-serv12631
Modified Files:
future.txt
Log Message:
Added feature request to future.txt.
To see the diffs for this commit:
http://www.druid.net/pygresql/viewcvs.cgi/cvs/pygresql/docs/future.txt.diff?r1=1.29r2=1.30
Durumdara schrieb:
I use Pygresql with DB2 api.
I tried to see the query structure, because I must export to Delphi.
But I cannot see real sizes (100, 100) of char/vchar.
Have I any way to get these character field sizes from the query?
You mean using the cursor.description attribute? That's
Greenberg, Gary schrieb:
There are no .pyc or .pyo files. Are they essential?
No, they are normally compiled automatically when imported.
There may be only a problem if you do the import with a user account who
does not have access right on the site-packages directory. But even if
in this
Greenberg, Gary wrote:
I need to supply pygresql module as a part of my application on Windows
platform.
Would it help you if I upload the files as easy_installable Python eggs
to PyPI?
It sure will, especially if you can provide some instructions, how to set it up.
Just noticed that
Kevin Ar18 schrieb:
I guess there's a few things I'd like to bring up
1. How is PyGreSQL's future? Is it still an active project?
As active as ever I would say.
2. Would it be insanely difficult for someone like me to hookup PyGreSQL to
SQLAlchemy?
No, it's probably as easy as
Kevin Ar18 schrieb:
I wonder...
Can I use pygresql to basically do the same thing as psycopg?
In particular, I need something that provides PostgreSQL suport for SQLAlchemy
(and web frameworks like django or Pylons which use SQLAlchemy).
Can I use pygresql instead?
PyGreSQL comes in two
Marcus Engene schrieb:
Are you against committing to the 'with' interface (__enter__, __exit__)
for cursors or has there just been no need for it?
It's already on our wish list (http://www.pygresql.org/future.html). The
main idea is that the exit method would commit or rollback
201 - 300 of 413 matches
Mail list logo
