search lists was broken in such a way that only the most recent
instance of a given hash code would ever be searched, thus possibly
missing longer matches further back. Fixing this gave 5 to 10%
compression improvement on some text test cases. Additional small
tweaks to improve speed of inner loops a little bit. There is no
compatibility issue created by this change, since the compressed data
format and decompression algorithm don't change.
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.
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
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
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.
typmod of a particular column, mark the output with that same typmod,
not -1 as formerly. -1 is still used if there is any disagreement.
Part of response to bug#513.
