such as BLCKSZ and MAXPGPATHLEN?

correctly (the lztext value will be promoted to text automatically).

into lztext.

Jan

relcache entry's reference count is zero.

Shouldn't create any portability problems, since we have a configure
test to #define away volatile if the compiler doesn't support it.

failures.  Fix some outright bugs too, including a reference to
uninitialized memory that would cause failures like this one:
select -('1234567890.1234567'::text);
ERROR:  Unable to locate type oid 2139062143 in catalog

This avoids the useless rebuild of pg_version that used to happen on
each build or install pass.

but we should get it out to beta testers.

for Thomas to do the datetime consolidation before touching this, but
it's done now...)

a specific length or precision, such as foo::char(8).  Remove erroneous
removal of user-written casts at the top level of a SELECT target item.

such as bpchar(char_expression, N), and pull out the attrtypmod that
the function is coercing to.  This allows correct deduction of the
column type in examples such as
CREATE VIEW v AS SELECT f1::char(8) FROM tbl;
Formerly we labeled v's column as char-of-unknown-length not char(8).
Also, this change causes the parser not to insert a redundant length
coercion function if the user has explicitly casted an INSERT or UPDATE
expression to the right length.

fields, nor with bpchar and varchar fields that have typmod -1.  The
latter effectively have an unspecified length, so I made them display
as char() and varchar() rather than falsely equating them to char(1)
and varchar(1).

refer to the single-byte char type.  7.0 was taking it as bpchar(1).

It worked, because they both have fields named 'data', but it's surely
trouble waiting to happen.  I wonder whether there are more ...

it's a good idea to choose the directory size based on the expected
number of entries.  But ShmemInitHash was using a hard-wired constant.
Boo hiss.  This accounts for recent report of postmaster failure when
asking for 64K or more buffers.