The problem occurs when there is a match to the pattern
overall but the user has specified a parenthesized
subexpression and that subexpression hasn't got a match. An
example is substring('foo' from
'foo(bar)?'). This should return NULL, since
(bar) isn't matched, but it was
mistakenly returning the whole-pattern match instead (ie,
foo).

This problem affects "old
style" (V0) C functions that return boolean. The fix
is already in 8.3, but the need to back-patch it was not
realized at the time.

Fix longstanding LISTEN/NOTIFY race
condition (Tom)

In rare cases a session that had just executed a
LISTEN might not get a
notification, even though one would be expected because the
concurrent transaction executing NOTIFY was observed to commit later.

A side effect of the fix is that a transaction that has
executed a not-yet-committed LISTEN command will not see any row in
pg_listener for the LISTEN, should it choose to look; formerly
it would have. This behavior was never documented one way
or the other, but it is possible that some applications
depend on the old behavior.

Fix display of constant expressions in ORDER BY and GROUP
BY (Tom)

An explictly casted constant would be shown incorrectly.
This could for example lead to corruption of a view
definition during dump and reload.

Fix libpq to handle
NOTICE messages correctly during COPY OUT (Tom)

This failure has only been observed to occur when a
user-defined datatype's output routine issues a NOTICE, but
there is no guarantee it couldn't happen due to other
causes.