of a counted input string. Marinos Yannikos' recent crash report turns
out to be due to applying pg_ascii2wchar_with_len to a TEXT object that
is smack up against the end of memory. This is the second just-barely-
reproducible bug report I have seen that traces to some bit of code
fetching one more byte than it is allowed to. Let's be more careful
out there, boys and girls.
While at it, I changed the code to not risk a similar crash when there
is a truncated multibyte character at the end of an input string. The
output in this case might not be the most reasonable output possible;
if anyone wants to improve it further, step right up...
succeeds or not. Revise rtree page split algorithm to take care about
making a feasible split --- ie, will the incoming tuple actually fit?
Failure to make a feasible split, combined with failure to notice the
failure, account for Jim Stone's recent bug report. I suspect that
hash and gist indices may have the same type of bug, but at least now
we'll get error messages rather than silent failures if so. Also clean
up rtree code to use Datum rather than char* where appropriate.
One more :)) It's for improper function argumets for
PLTCL_UNKNOWN_SUPPORT code
I'm not an autoconf expert, but is it possible to enable unknown
support in pltcl with configure option ?
This support is really handy for real life usage of pl/tcl.
seva@sevasoft.kiev.ua
not all of them attached properly in the post I made a few minutes
ago. Please disregard those earlier files. The diffs in the tar file
replace them.
Pierce Tyler
(said redirection required when run).
After checking using cvsweb, removed the offending conflict.
Rebuilt configure using autoconf, and it now works fine.
bits in JDBC & the first set of tools into contrib.
This is the third, and deals with enabling JDBC to be compiled with the main
source.
What it does is add a new option to configure: --with-java
This option tells configure to look for ant (our build tool of choice) and
if found, it then compiles both the JDBC driver and the new tools as part
of the normal make.
Also, when the postgresql install is done, all the .jar files are also
installed into the ${PGLIB}/java directory (thought best to keep then separate)
Now I had some conflicts when this applied so could someone please double check
that everything is ok?
Peter
am talking with Thomas Lockhart about the idea of bringing the PyGreSQL
version number into alignment with PostgreSQL so this may change to 7.1
before the release.
I have added to the copyright to indicate that from now on the PostgreSQL
copyright will apply. If someone wants to make that clearer please do.
The existing copyrights need to stay there for now but if necessary I can
ask Pascal Andre if he agrees to a different wording.
Added reference to the Python DB-API 2.0 compliant API wrapper.
Added reference to the PyGreSQL mailing list.
