This seems the right thing for most usages, but I notice two places
where it is the wrong thing.  One is that the default permissions on
TOAST rels should be no-access, not world-readable; the other is that
PrepareForTupleInvalidation doesn't really need to spend time looking
at tuples of TOAST relations.

Kevin Jacobs and Brad McLean.

and comment in src/backend/parser/Makefile for the technical details.

discussions in pghackers.

mutually exclusive keyword lists spanning all known keywords ---
including AS.  Moved COALESCE and a few other ColLabels into the
can-be-ColId list.

round of editorial effort.

to reverse-engineer documentation for them.

int8, int16, int32, int64 and separately uint8, uint16, uint32, uint64

The previous patch grouped:
int8, int16 and int32
uint8, uint16 and uint32
int64 and uint64  <-- this grouping is wrong on AIX 4.3.3 and below

If you prefer to make 4 groups out of this you could apply this patch.

Andreas

Peter E, Tatsuo, Andreas

with reality, and add doco for Jan's recent round of enhancements.

in C, but recommend that newbies who don't recognize this trick should do
some studying ...

There's also a little fix for the getRow() method. While fixing
absolute(), I noticed that getRow() wasn't quite following the spec: it
wasn't returning 0 when the ResultSet wasn't positioned on a row.  I've
started a ResultSet test case and included it as well.

Liam Stewart

destination in plpgsql.

bpchar, bit, numeric with typmod -1.  Alter format_type so that this
representation is printed when the typmod is -1.  This ensures that
tables having such columns can be pg_dump'd and reloaded correctly.
Also, remove the rather useless and non-SQL-compliant default
precision and scale for type NUMERIC.  A numeric column declared as
such (with no precision/scale) will now have typmod -1 which means
that numeric values of any precision/scale can be stored in it,
without conversion to a uniform scale.  This seems significantly
more useful than the former behavior.  Part of response to bug #513.

use that typmod not -1 as the typmod of the CASE result.
Part of response to bug#513.