built-in procedures are named after the prosrc field of pg_proc (ie,
the actual C function name), not the proname field.  This did not use
to make a difference back when the two were always the same, but in the
presence of overloaded proname values we'd best try to use the C name
instead.  AFAICT this change affects no existing code, but it is
necessary to be able to get at some built-in functions that no macro
was being generated for before.

to 10, and be consistent about whether it counts the trailing null (it
does not).  Also increase MAXDATELEN to be sure no buffer overflows are
caused by the longer MAXTZLEN.

the src/include tree, so that -I backend is no longer necessary anywhere.
Also, clean up some bit rot in contrib tree.

CurrentTriggerData is history.

pg_language entries.

that have at least one constant-NULL input, even if other inputs are
not constants.

Need to update user docs still ...

key call sites are changed, but most called functions are still oldstyle.
An exception is that the PL managers are updated (so, for example, NULL
handling now behaves as expected in plperl and plpgsql functions).
NOTE initdb is forced due to added column in pg_proc.

necessary to call isatty() for each and every received query.  That's
one less kernel call per query cycle ...

Most (nearly all) of the work was done by David Wragg <dpw@doc.ic.ac.uk>

He patched 6.5.3. I've updated it for 7.0RC5.

It works for MIT kerberos 1.1.1 (and previously for 1.0.6 as well).

I've got the patch against 6.5.3, plus kerberized RPMS.

Mike Wyer <mw@doc.ic.ac.uk>     ||         "Woof?"

other than the most common value in a column.  We had had 0.5, make it
0.1 to make it more likely that an indexscan will be chosen.  Really
need better statistics instead, but this should stem the bleeding
meanwhile ...

to an undecorated relation name (cf. example from Ed Loehr, 5/25/00).

since-closed file descriptors...

subsequent I/O attempts fail cleanly.  I'm speculating about failure
scenarios in which we do pq_close, then something in a proc_exit routine
opens a file (re-using that kernel FD number), then something else
fails and tries to write an elog message to the frontend ... message
ends up in opened file, oops.  No known examples of this but it seems
like a potential hole.