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.
>
> 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],))
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.
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
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.
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
