Make FUNC_MAX_ARGS equal INDEX_MAX_KEYS, as it should.
Set default INDEX_MAX_KEYS to 16.  Document minimum safe value is 9.

oid8 => oidvector in alter_table regress test

Another FUNC_MAX_ARGS tweak.

Update struct Trigger definition.

Wrong boundary condition on number-of-args check.

Ah-hah, there are attribute size constants lurking here too.

Use symbolic INDEX_MAX_KEYS in pg_type entries for oidvector
and int2vector.

Correct hardwired type information in bootstrap.

Remove no-longer-used symbols.

More cleanups.  Still doesn't work.

More cleanups.

More fixes, but still need +1 for FUNC_MAX_ARGS

Remove outdated comment about 8 arguments.

Change oid8/int28 -> oidvector/int2vector.

Fix initdb so it works, but still only for 8.

Update type stuff.

Cleanup for func args > 8.

More updates for function call interface > 8.

Update fmgr to allow 32 arguments.

Make number of args to a function configurable.

Rename oid8 -> oidvector and int28 -> int2vector.  Cleanup of *out functions.

Update int28out and out8out and _in_ functions to handle trailing zeros
properly.

Update TODO list.

Improve cache invalidation handling. Eespecially
this would fix TODO
* elog() flushes cache, try invalidating just entries from
  current xact, perhaps using invalidation cache

Fix oid8in and int28in for spaces

Move fixes for >8 indexed fields.

Move INDEX_MAX_KEYS to postgres.h, and make it configurable for users.

Update TODO list.

Repair subtle VACUUM bug that led to 'HEAP_MOVED_IN was not expected'
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 be
specified by regular-expression patterns.  Add some more files.

install_plpgsql is no longer a regress test (it's done via createlang);
remove the no-longer-used files.

The psql online help for ALTER TABLE (\h alter table) is corrupt.  I
traced this back to what I believe is an error in the sgml file used to
generate this comment, found in pgsql/doc/src/sgml/ref/alter_table.sgml.

Stephen Birch

Add SetPidFile() and friends.

Do not start if postmaster is running.

Move SetPidFile() and firends to utils/init/miscinit.c from
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 that
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)
Do not start postmaster if postgres is running

New scheme for managing platform-specific regress test result files.
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.

First examples of multiplatform result comparison files.

Remove obsolete platform-specific regress test comparison files.
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 had
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'.

Update remaining tests for new psql, with the exception of 'arrays',
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_.

Another round of planner/optimizer work.  This is just restructuring and
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 in
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 sanely
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,
as well as when inserting entries into an existing index.

Sorry, that I send this letter/patch again, but previous sending is
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 error

*** empty log message ***

Update pg_dumpall for new psql format.

Changed "triggered data change violation" detection code
in trigger manager.

Jan

Fixed bug in targetlist expression replacement of
SET DEFAULT referential action triggers.

Jan

Clean up header for uniform appearance throughout tests.

Update for new psql formatting.

Freshen up the banner displayed when running the regression test.

Fix it's and its to be correct.

Update format to add uniform headers on files.

Update format to add uniform headers on files.
Update output to new psql conventions.

Update output to new psql conventions.

Fix spaces in text message.

Clean up format of tests.
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.
Include a few new tests for datetime/timespan arithmetic.

Move numeric test to be near other numeric data types like int4 and float8.

Clean up syntax to use SQL92-ish type coersion
 rather than the Postgres "::" notation.
All of these tests have been completely inspected and give correct results.

Match results with format from new psql.
All of these tests have been completely inspected and give correct results.

Repair two recently reported problems:
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.

Update length of timestamp to 30.

Remove DATEDEBUG because it didn't look Y2K safe, and fix timestamp elog
to be Y2K safe.

Make psql \dT always show descriptions.  There is room.

Generate double-sided LIKE indexquals that work even in weird locales,
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 generate
<= 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.

Revise init_sequence so that it doesn't leak memory if the requested
sequence doesn't exist.

elog() was set up to call abort() if it saw an ERROR or FATAL exit
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.

Clearify DECLARE syntax by saying cursorname, not just cursor.

Allow --with-mb=SQL_ASCII

Repair bugs discussed in pghackers thread of 15 May 1999: creation of a
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 returned
by subselect used as expression."

Move ipc patch into README.NT.

Add NT patch.

Move NT patch into readme.

Update comment.

Update comments.

Removed LZTEXT datatype as discussed.

Jan

Fix length limit, MikeA

Hi, all,

This is the patch for the final bit.  Sorry that it's separate.

Cheers...

MikeA

Hi, all

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.

It turns out that the item size limit for btree indexes is about BLCKSZ/3,
not BLCKSZ/2 as some of us thought.  Add check for oversize item so that
failure is detected before corrupting the index, not after.

Update developers faq.

Clean up handling of explicit NULL constants.  Cases like
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 ***

Fix minor bug.

Add installtion of postmaster.opts.default.

Add installation of pg_ctl
Locate path of postmaster in a portable way (stolen from initdb)
Add postmaster.opts.default.sample which should be copied into
$PGLIB in the installtion process. Also, it will be installed into
$PGDATA while initdb is running.

to live in a transaction before access to db
during backend startup.