| Age | Commit message (Collapse) | Author |
|---|
|
recently. I just ran into it while running a set of python test scripts,
and I'm not sure who the normal maintainer is for interfaces/python.
John Nield
|
|
since we moved from an implicate to explicate implementation.
Greg Copeland
|
|
syscat.py scripts were both modified. pg.py uses it to cache a list of
pks (which is seemingly does for every db connection) and various
attributes. syscat uses it to walk the list of system tables and
queries the various attributes from these tables.
In both cases, it seemingly makes sense to apply what you've requested.
Greg Copeland
|
|
saw a fix offered up. Since I'm gearing up to use Postgres and Python
soon, I figured I'd have a hand at trying to get this sucker addressed.
Apologies if this has already been plugged. I looked in the archives
and never saw a response.
At any rate, I must admit I don't think I fully understand the
implications of some of the changes I made even though they appear to be
straight forward. We all know the devil is in the details. Anyone more
knowledgeable is requested to review my changes. :(
I also updated the advanced.py script in a somewhat nonsensical fashion
to make use of an int8 field in an effort to test this change. It seems
to run okay, however, this is by no means an all exhaustive test. So,
it's possible that a bumpy road may lay ahead for some. On the other
hand...overflows (hopefully) previously lurked (long -> int conversion).
Greg Copeland
|
|
with the Cursor object's fetchmany() method. The API and
inline documentation state that the default is 1. It
currently defaults to 5.
Patrick Macdonald
|
|
|
|
|
|
Slackware 8), and perhaps on other Pythons, haven't checked. Something in
the _pg.connect() call isn't working. I think the problem stems from the
fact that 'host' is a named parameter of both _pg.connect and pgdb.connect,
and so Python treats it as a variable assignment, not a named parameter.
Uses non-named parameters.
Andrew Johnson
|
|
|
|
|
|
entries, per pghackers discussion. This fixes aggregates to live in
namespaces, and also simplifies/speeds up lookup in parse_func.c.
Also, add a 'proimplicit' flag to pg_proc that controls whether a type
coercion function may be invoked implicitly, or only explicitly. The
current settings of these flags are more permissive than I would like,
but we will need to debate and refine the behavior; for now, I avoided
breaking regression tests as much as I could.
|
|
|
|
|
|
- Use PyObject_Del() rather than macro version
- Check version and drop back to PyMem_Del() for older systems.
|
|
compiled with --with-pymalloc. This change fixes that. Thanks to
Dave Wallace <dwallace@udel.edu>
|
|
|
|
|
|
>
> I am running Python 1.5.
Therein lies the problem... :)
Since it appears you have the requirement of supporting old python
versions, attached is just the pgdb.py part of the patch (with a fix for
DateTime handling). It has the same functionality but certainly won't be
quite as fast. Given the absence of _PyString_Join in python1.5, it's a
pain to get the C variants working for all versions. The pgdb.py patch
does leaves the hooks in, should someone wish to do the optimization at a
later point.
Elliot Lee
|
|
Elliot Lee wrote:
> This patch to the python bindings adds C versions of the often-used
query
> args quoting routines, as well as support for quoting lists e.g.
> dbc.execute("SELECT * FROM foo WHERE blah IN %s", ([1,2,3],))
|
|
query args quoting routines, as well as support for quoting lists e.g.
dbc.execute("SELECT * FROM foo WHERE blah IN %s", ([1,2,3],))
Elliot Lee
|
|
|
|
the latest version and I wanted to make sure that there was a clean release.
I also change the build files as I discussed in my letter of Nov 6, 2001. At
the time I was asked to hold off until after the release.
|
|
the interactive docs.
|
|
initdb/regression tests pass.
|
|
of the documentation in preparation for upcoming release.
|
|
|
|
make it clearer that d was the argument to the format operator.
|
|
spacing. Also adds space for one-line comments.
|
|
tests pass.
|
|
> results of every fetch).
Stephen Robert Norris
|
|
view when using the aggregate function count() and function nextval
that returns an int8 value, but in python is represented like string:
>> db.query("select nextval('my_seq')").getresult()
[('2',)]
>> db.query("select count(*) from films").dictresult()
[{'count': '120'}]
Ricardo Caesar Lenzi
|
|
Fixed a nasty bug that messed up negative money amounts.
|
|
|
|
places that were including the wrong files.
|
|
the first result in the DB-API compliant wrapper. It turned out that the bug
was way down in the C code.
Gerhard Häring
|
|
|
|
choice of compiler and flags, uninstall, and peculiar Python installation
layouts for PyGreSql. Also install into site-packages now, as officially
recommended. And pgdb.py is also installed now, used to be forgotten.
|
|
oid values.
|
|
|
|
make sure that we are using the right #defines in pgmodule.c but the
OIDs are never actually expected to change.
|
|
Thanks to Steve McClure <smcclure@racemi.com> for the patch.
|
|
|
|
could be changed if we create a new Python type that matches it better
but NUMERIC <==> FLOAT probably works fine for most cases.
|
|
Python) to support shared extension modules, I have learned that Guido
prefers the style of the attached patch to solve the above problem.
I feel that this solution is particularly appropriate in this case
because the following:
PglargeType
PgType
PgQueryType
are already being handled in the way that I am proposing for PgSourceType.
Jason Tishler
|
|
> > The attached patch changes src/interfaces/python/GNUmakefile to use the
> > value of DESTDIR like the rest (or at least most) of the PostgreSQL
> > makefiles. I found this problem when trying to package a pre-built
> > Cygwin PostgreSQL distribution, but this problem is platform independent.
|
|
value of DESTDIR like the rest (or at least most) of the PostgreSQL
makefiles. I found this problem when trying to package a pre-built
Cygwin PostgreSQL distribution, but this problem is platform independent.
The problem manifests itself when one tries to install into a stagging
area (e.g., to build a tarball) instead of a real install. In this case,
pg.py and _pgmodule$(SO) still end up being installed in the configured
prefix directory ignoring the value of DESTDIR.
Unfortunately, this patch does not handle the case where PostgreSQL
and Python are configured with different prefixes. Since the Python
Makefile is automatically generated and does not use DESTDIR, I believe
that this issue will be difficult to correct. If anyone has ideas on
how to fix this issue, then I'm quite willing to rework the patch to
take the suggestion into account.
Jason Tishler
|
|
|
|
there's no shared libpython. Test suite works as well. Also, add some
documentation.
|
|
the way to handle this.
|
|
properly on 64 bit systems.
Change submitted by Marc Poinot (Marc.Poinot@onera.fr)
|
