- 10 Mar, 2001 7 commits
-
-
Tom Lane authored
-
Bruce Momjian authored
-
Peter Eisentraut authored
-
Peter Eisentraut authored
of DSSSL.
-
Peter Eisentraut authored
-
Tom Lane authored
under the postmaster --- specifically, if we are a standalone backend running under the initdb script, this is critical!
-
Hiroshi Inoue authored
2)Fix some memory leaks. 3)Change some bogus error messages.
-
- 09 Mar, 2001 4 commits
-
-
Tom Lane authored
-
Peter Eisentraut authored
handle this.
-
Peter Eisentraut authored
-
Hiroshi Inoue authored
-
- 08 Mar, 2001 5 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Tom Lane authored
be allowed to receive ungrouped variables of the current query level. Curious that no one reported this bug before...
-
Tom Lane authored
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...
-
- 07 Mar, 2001 3 commits
-
-
Tom Lane authored
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.
-
Bruce Momjian authored
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
-
Bruce Momjian authored
in splitting code: seva@sevasoft.kiev.ua
-
- 06 Mar, 2001 12 commits
-
-
Bruce Momjian authored
-
Tom Lane authored
directories, per suggestion from Robert Creager.
-
Peter Eisentraut authored
-
Peter Eisentraut authored
-
Peter Eisentraut authored
-
Bruce Momjian authored
-
Peter Eisentraut authored
-
Peter Mount authored
- Removed org.postgresql.xa.Test from the JDBC EE driver as it's an old test class and prevented it from compiling.
-
Philip Warner authored
-
Philip Warner authored
-
Philip Warner authored
- Prevent double-dumping of sequences when dataOnly.
-
Philip Warner authored
- Change -U option to -L to allow -U to specify username in future. (pg_restore)
-
- 05 Mar, 2001 9 commits
-
-
Peter Eisentraut authored
-
Peter Eisentraut authored
-
Bruce Momjian authored
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
-
Bruce Momjian authored
-
Bruce Momjian authored
Here is the chinese_big5 patch for PgAccess. I've tested under Chinese Windows 2000 without any problem. Have fun. LM.Liu
-
Peter Mount authored
(said redirection required when run). After checking using cvsweb, removed the offending conflict. Rebuilt configure using autoconf, and it now works fine.
-
Peter Mount authored
Found while testing against a full checkout. Peter
-
Peter Mount authored
Ok, I've split todays commit into three, the first two already done had some 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
-
Peter Mount authored
-