aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Cleanup for func args > 8.Bruce Momjian2000-01-10
|
* More updates for function call interface > 8.Bruce Momjian2000-01-10
|
* Update fmgr to allow 32 arguments.Bruce Momjian2000-01-10
|
* Make number of args to a function configurable.Bruce Momjian2000-01-10
|
* Rename oid8 -> oidvector and int28 -> int2vector. Cleanup of *out functions.Bruce Momjian2000-01-10
|
* Update int28out and out8out and _in_ functions to handle trailing zerosBruce Momjian2000-01-10
| | | | properly.
* Improve cache invalidation handling. EespeciallyHiroshi Inoue2000-01-10
| | | | | | this would fix TODO * elog() flushes cache, try invalidating just entries from current xact, perhaps using invalidation cache
* Fix oid8in and int28in for spacesBruce Momjian2000-01-10
|
* Move fixes for >8 indexed fields.Bruce Momjian2000-01-10
|
* Move INDEX_MAX_KEYS to postgres.h, and make it configurable for users.Bruce Momjian2000-01-10
|
* Repair subtle VACUUM bug that led to 'HEAP_MOVED_IN was not expected'Tom Lane2000-01-10
| | | | | | | | | | | | | | | | | | errors. VACUUM normally compacts the table back-to-front, and stops as soon as it gets to a page that it has moved some tuples onto. (This logic doesn't make for a complete packing of the table, but it should be pretty close.) But the way it was checking whether it had got to a page with some moved-in tuples was to look at whether the current page was the same as the last page of the list of pages that have enough free space to be move-in targets. And there was other code that would remove pages from that list once they got full. There was a kluge that prevented the last list entry from being removed, but it didn't get the job done. Fixed by keeping a separate variable that contains the largest block number into which a tuple has been moved. There's no longer any need to protect the last element of the fraged_pages list. Also, fix NOTICE messages to describe elapsed user/system CPU time correctly.
* Update platform-specific-expected-file support so that platforms can beTom Lane2000-01-09
| | | | specified by regular-expression patterns. Add some more files.
* install_plpgsql is no longer a regress test (it's done via createlang);Tom Lane2000-01-09
| | | | remove the no-longer-used files.
* Add SetPidFile() and friends.Tatsuo Ishii2000-01-09
|
* Do not start if postmaster is running.Tatsuo Ishii2000-01-09
|
* Move SetPidFile() and firends to utils/init/miscinit.c fromTatsuo Ishii2000-01-09
| | | | | | postmaster/postmaster.c so that tcop/postgres.c can use them. Now we have an interlock between postmaster and postgres.
* Move SetPidFile() and firends to utils/init/miscinit.c so thatTatsuo Ishii2000-01-09
| | | | | tcop/postgres.c can use them. Now we have an interlock between postmaster and postgres.
* Add more portability to echo -n (code stolen from createlang)Tatsuo Ishii2000-01-09
| | | | Do not start postmaster if postgres is running
* New scheme for managing platform-specific regress test result files.Tom Lane2000-01-09
| | | | | | | Instead of hard-wiring one result file per platform, there is a map file 'resultmap' that says which one to use --- a lot like template/.similar. I have only created entries in resultmap for my own platform (HPUX) so far; feel free to add lines for other platforms.
* Remove obsolete platform-specific comparison files.Tom Lane2000-01-09
|
* First examples of multiplatform result comparison files.Tom Lane2000-01-09
|
* Remove obsolete platform-specific regress test comparison files.Tom Lane2000-01-09
| | | | | Note: don't put any of these back till you've grokked the new code for platform-specific comparisons that I'm about to commit...
* Remove CVS $Header lines from a couple of regress test files that hadTom Lane2000-01-09
| | | | | them --- it is just *way* too painful to keep expected results in sync when these are present.
* Update remaining tests for new psql, with the exception of 'arrays'.Tom Lane2000-01-09
|
* Update remaining tests for new psql, with the exception of 'arrays',Tom Lane2000-01-09
| | | | | | | which is broken in some weird way that I don't understand. I think it may be exposing a bug in the new psql --- for one thing, I get different results when I run psql by hand than the regress script gets. What the heck???
* 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.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 13:18:43 +0000