| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
| |
it, and map that to close() on Unix.
|
|
|
|
| |
Keep PQfreeNotify() around for binary compatibility.
|
|
|
|
|
|
| |
PostgreSQL source code.
Neil Conway
|
|
|
|
|
| |
logic carefully and I am sure that the test against n happens after it
is assigned to.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
=====================
I suggested an improvement of the inserttable in the PyGreSQL interface
already in January, but seemingly it was never implemented. I was told this
is the right place to get patches in for PyGreSQL, so I'm reposting my patch
here.
I consider the inserttable methode essential in populating the database
because of its benefits in performance compared to insert, so I think this
patch is quite essential. The attachment is an improved version of the
corresponding pg_inserttable function in pgmodule.c, which fixes the
following problems:
* The function raised exceptions because PyList_GetItem was used beyond the
size of the list. This was checked by comparing the result with NULL, but
the exception was not cleaned up, which could result in mysterious errors in
the following Python code. Instead of clearing the exception using
PyErr_Clear or something like that, I avoided throwing the exception at all
by at first requesting the size of the list. Using this opportunity, I also
checked the uniformity of the size of the rows passed in the lists/tuples.
The function also accepts (and silently ignores) empty lists and sublists.
* Python "None" values are now accepted and properly converted to PostgreSQL
NULL values
* The function now generates an error message in case of a line buffer
overflow
* It copes with tabulators, newlines and backslashes in strings now
* Rewrote the buffer filling code which should now run faster by avoiding
unnecessary string copy operations forth and back
Christoph Zwerschke
|
| |
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
| |
- 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>
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
initdb/regression tests pass.
|
|
|
|
| |
of the documentation in preparation for upcoming release.
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
oid values.
|
| |
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
properly on 64 bit systems.
Change submitted by Marc Poinot (Marc.Poinot@onera.fr)
|
| |
|
| |
|
|
|
|
|
| |
Changed the way that OID is retrieved on inserts. PQoidStatus appears
to be deprecated so I am using PQoidValue instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix some quoting functions. In particular handle NULLs better.
Use a method to add primary key information rather than direct
manipulation of the class structures.
Break decimal out in _quote (in pg.py) and treat it as float.
Treat timestamp like date for quoting purposes.
Remove a redundant SELECT from the get method speeding it, and
insert since it calls get, up a little.
Add test for BOOL type in typecast method to pgdbTypeCache class.
(tv@beamnet.de)
Fix pgdb.py to send port as integer to lower level function
(dildog@l0pht.com)
Change pg.py to speed up some operations
Allow updates on tables with no primary keys.
D'Arcy J.M. Cain
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that now functions as a wrapper around the MakeMaker stuff. It might
even behave sensically when we have separate build dirs. Same for plperl,
which of course still doesn't work very well. Made sure that plperl
respects the choice of --libdir.
Added --with-python to automatically build and install the Python interface.
Works similarly to the Perl5 stuff.
Moved the burden of the distclean targets lower down into the source tree.
Eventually, each make file should have its own.
Added automatic remaking of makefiles and configure. Currently only for the
top-level because of a bug(?) in Autoconf. Use GNU `missing' to work around
missing autoconf and aclocal. Start factoring out macros into their own
config/*.m4 files to increase readability and organization.
|
| |
|
| |
|
| |
|
|
|
|
| |
From: D'Arcy J.M. Cain <darcy@druid.net>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
been applied. The patches are in the .tar.gz attachment at the end:
varchar-array.patch this patch adds support for arrays of bpchar() and
varchar(), which where always missing from postgres.
These datatypes can be used to replace the _char4,
_char8, etc., which were dropped some time ago.
block-size.patch this patch fixes many errors in the parser and other
program which happen with very large query statements
(> 8K) when using a page size larger than 8192.
This patch is needed if you want to submit queries
larger than 8K. Postgres supports tuples up to 32K
but you can't insert them because you can't submit
queries larger than 8K. My patch fixes this problem.
The patch also replaces all the occurrences of `8192'
and `1<<13' in the sources with the proper constants
defined in include files. You should now never find
8192 hardwired in C code, just to make code clearer.
--
Massimo Dal Zotto
|
| |
|
| |
|
| |
|
|
|