aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Fix some missing substitutions of _OBJWD_ and _DLSUFFIX_.Tom Lane2000-01-09
|
* Another round of planner/optimizer work. This is just restructuring andTom Lane2000-01-09
| | | | | code cleanup; no major improvements yet. However, EXPLAIN does produce more intuitive outputs for nested loops with indexscans now...
* This patch removes the initialization of ri in loop inBruce Momjian2000-01-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | quote_postgres(...) in ecpglib.c. The code in CVS reads: quote_postgres(char *arg, int lineno) { char *res = (char *) ecpg_alloc(2 * strlen(arg) + 3, lineno); int i, ri = 0; if (!res) return (res); res[ri++] = '\''; for (i = 0, ri=0; arg[i]; i++, ri++) { switch (arg[i]) { case '\'': res[ri++] = '\''; break; case '\\': res[ri++] = '\\'; break; default: ; } The problem here is that ri is reset to 0, thus overwriting the initial quote. Stephen Birch
* Modify PageIsEmpty and PageGetMaxOffsetNumber macros to behave sanelyTom Lane2000-01-08
| | | | | | | | | if presented an uninitialized (all zeroes) page. The system no longer crashes hard if an all-zeroes page is present in a relation. There seem to be some boundary conditions where a page will be appended to a relation and zeroed, but its page header is never initialized; until we can track down and fix all of those, robustness seems like a good idea. Also, clean up some obsolete and downright wrong comments.
* Need defense against oversize index entries in btree CREATE INDEX,Tom Lane2000-01-08
| | | | as well as when inserting entries into an existing index.
* Sorry, that I send this letter/patch again, but previous sending isBruce Momjian2000-01-07
| | | | | | | | | still without answer. I want continue with to_char(), but I need any answer for this patch. Please. Thank! (and sorry of my impatient :-) Karel
* Correct grammatical errorTatsuo Ishii2000-01-07
|
* *** empty log message ***Michael Meskes2000-01-07
|
* Update pg_dumpall for new psql format.Bruce Momjian2000-01-06
|
* Changed "triggered data change violation" detection codeJan Wieck2000-01-06
| | | | | | in trigger manager. Jan
* Fixed bug in targetlist expression replacement ofJan Wieck2000-01-06
| | | | | | SET DEFAULT referential action triggers. Jan
* Clean up header for uniform appearance throughout tests.Thomas G. Lockhart2000-01-06
|
* Update for new psql formatting.Thomas G. Lockhart2000-01-06
|
* Freshen up the banner displayed when running the regression test.Thomas G. Lockhart2000-01-06
|
* Fix it's and its to be correct.Bruce Momjian2000-01-05
|
* Update format to add uniform headers on files.Thomas G. Lockhart2000-01-05
|
* Update format to add uniform headers on files.Thomas G. Lockhart2000-01-05
| | | | Update output to new psql conventions.
* Update output to new psql conventions.Thomas G. Lockhart2000-01-05
|
* Fix spaces in text message.Thomas G. Lockhart2000-01-05
|
* Clean up format of tests.Thomas G. Lockhart2000-01-05
| | | | | Remove older "::" type coersion syntax in favor of extended SQL92 style. Include a few new tests for datetime/timespan arithmetic.
* Verified output from new psql.Thomas G. Lockhart2000-01-05
| | | | Include a few new tests for datetime/timespan arithmetic.
* Move numeric test to be near other numeric data types like int4 and float8.Thomas G. Lockhart2000-01-05
|
* Clean up syntax to use SQL92-ish type coersionThomas G. Lockhart2000-01-04
| | | | | rather than the Postgres "::" notation. All of these tests have been completely inspected and give correct results.
* Match results with format from new psql.Thomas G. Lockhart2000-01-04
| | | | All of these tests have been completely inspected and give correct results.
* Repair two recently reported problems:Thomas G. Lockhart2000-01-04
| | | | | | | | | | | | | | | | 1) datetime_pl_span() added the seconds field before adding the months field. This lead to erroneous results for e.g. select datetime '1999-11-30' + timespan '1 mon - 1 sec'; Reverse the order of operations to add months first. 2) tm2timespan() did all intermediate math as integer, converting to double at the very end. This resulted in hidden overflows when given very large integer days, hours, etc. For example, select '74565 days'::timespan; produced the wrong result. Change code to ensure that doubles are used for intermediate calculations. Thanks to Olivier PRENANT <ohp@pyrenet.fr> and Tulassay Zsolt <zsolt@tek.bke.hu> for problem reports and to Tom Lane for accurate analyses.
* Update DATEDEBUG removal.Bruce Momjian2000-01-02
|
* Update length of timestamp to 30.Bruce Momjian2000-01-02
|
* Remove DATEDEBUG because it didn't look Y2K safe, and fix timestamp elogBruce Momjian2000-01-02
| | | | to be Y2K safe.
* Make psql \dT always show descriptions. There is room.Bruce Momjian1999-12-31
|
* Generate double-sided LIKE indexquals that work even in weird locales,Tom Lane1999-12-31
| | | | | by continuing to increment the rightmost character until we get a string that is demonstrably greater than the pattern prefix.
* Clean up loose end in LIKE optimization fix: parser's code would generateTom Lane1999-12-31
| | | | | <= and >= indexquals from a LIKE even if the index in question didn't support those operators. (As, for example, a hash index does not.)
* Clean up datatypes and comments for op_class() routine.Tom Lane1999-12-31
|
* Revise init_sequence so that it doesn't leak memory if the requestedTom Lane1999-12-31
| | | | sequence doesn't exist.
* elog() was set up to call abort() if it saw an ERROR or FATAL exitTom Lane1999-12-30
| | | | | | | | | | during InitProcessingMode and the CurrentTransactionState was neither TRANS_DEFAULT nor TRANS_DISABLED. Unfortunately, after someone's recent change to start the transaction manager earlier in startup than it used to be started, that caused an abort() and consequent database system reset on quite harmless errors (such as rejecting an invalid user name!). As far as I can see, the test on CurrentTransactionState was completely useless anyway, so I've removed it.
* Allow --with-mb=SQL_ASCIITatsuo Ishii1999-12-30
|
* Repair bugs discussed in pghackers thread of 15 May 1999: creation of aTom Lane1999-12-30
| | | | | | relcache entry no longer leaks a small amount of memory. index_endscan now releases all the memory acquired by index_beginscan, so callers of it should NOT pfree the scan descriptor anymore.
* Improve subquery error message, now says "More than one tuple returnedBruce Momjian1999-12-29
| | | | by subselect used as expression."
* Move ipc patch into README.NT.Bruce Momjian1999-12-29
|
* Add NT patch.Bruce Momjian1999-12-29
|
* Move NT patch into readme.Bruce Momjian1999-12-29
|
* Update comment.Bruce Momjian1999-12-29
|
* Update comments.Bruce Momjian1999-12-29
|
* Removed LZTEXT datatype as discussed.Jan Wieck1999-12-28
| | | | Jan
* Fix length limit, MikeABruce Momjian1999-12-27
|
* Hi, all,Bruce Momjian1999-12-27
| | | | | | | | | This is the patch for the final bit. Sorry that it's separate. Cheers... MikeA
* Hi, allBruce Momjian1999-12-27
| | | | | | | | | | | | | I finally got around to schlepping through pg_dump, to finish what I started about three months (or more) ago. Attached is a gzipped diff file to apply in the bin/pg_dump directory. This should remove all string length dependencies, except one, which I'm working on. It has been through some rudimentary unit testing, but that's about it, so if any of you would give it a more strenuous run-through, I'd be grateful for the feedback. Cheers... Ansley, Michael
* Put back erroneously-removed definition of 'defines' variable.Tom Lane1999-12-26
|
* It turns out that the item size limit for btree indexes is about BLCKSZ/3,Tom Lane1999-12-26
| | | | | not BLCKSZ/2 as some of us thought. Add check for oversize item so that failure is detected before corrupting the index, not after.
* Clean up handling of explicit NULL constants. Cases likeTom Lane1999-12-24
| | | | | | | | | | | | | SELECT null::text; SELECT int4fac(null); work as expected now. In some cases a NULL must be surrounded by parentheses: SELECT 2 + null; fails SELECT 2 + (null); OK This is a grammatical ambiguity that seems difficult to avoid. Other than that, NULLs seem to behave about like you'd expect. The internal implementation is that NULL constants are typed as UNKNOWN (like untyped string constants) until the parser can deduce the right type.
* *** empty log message ***Michael Meskes1999-12-23
|