delta/postgresql.git, branch REL8_0_21

tag 8.0.21

2009-03-13T02:30:37+00:00

Update back-branch release notes.

2009-03-12T22:36:33+00:00

Fix core dump due to null-pointer dereference in to_char() when datetime

2009-03-12T00:53:56+00:00

format codes are misapplied to a numeric argument.  (The code still produces
a pretty bogus error message in such cases, but I'll settle for stopping the
crash for now.)  Per bug #4700 from Sergey Burladyan.

Problem exists in all supported branches, so patch all the way back.
In HEAD, also clean up some ugly coding in the nearby cache management
code.

Add MUST (Mauritius Island Summer Time) to the list of known abbreviations.

2009-03-05T14:29:12+00:00

Mauritius began using DST in the summer 2008-2009; the Olson library has been
updated already.

Xavier Bugaud

Put back our old workaround for machines that declare cbrt() in math.h but

2009-03-04T22:08:46+00:00

fail to provide the function itself.  Not sure how we escaped testing anything
later than 7.3 on such cases, but they still exist, as per André Volpato's
report about AIX 5.3.

Ooops ... fix some confusion between gettext() and _() in my previous patch.

2009-03-03T00:17:36+00:00

This has moved around in past releases, so just copying-and-pasting from HEAD
didn't work as intended.

When we are in error recursion trouble, arrange to suppress translation and

2009-03-02T21:19:14+00:00

encoding conversion of any elog/ereport message being sent to the frontend.
This generalizes a patch that I put in last October, which suppressed
translation of only specific messages known to be associated with recursive
can't-translate-the-message behavior.  As shown in bug #4680, we need a more
general answer in order to have some hope of coping with broken encoding
conversion setups.  This approach seems a good deal less klugy anyway.

Patch in all supported branches.

Fix buffer allocations in encoding conversion routines so that they won't

2009-02-28T18:50:14+00:00

fail on zero-length inputs.  This isn't an issue in normal use because the
conversion infrastructure skips calling the converters for empty strings.
However a problem was created by yesterday's patch to check whether the
right conversion function is supplied in CREATE CONVERSION.  The most
future-proof fix seems to be to make the converters safe for this corner case.

In CREATE CONVERSION, test that the given function is a valid conversion

2009-02-27T16:35:47+00:00

function for the specified source and destination encodings. We do that by
calling the function with an empty string. If it can't perform the requested
conversion, it will throw an error.

Backport to 7.4 - 8.3. Per bug report #4680 by Denis Afonin.

commit first then tag 8.0.20

2009-01-30T04:59:15+00:00