Release 8.2.20

E.188.1. Migration to Version 8.2.20

A dump/restore is not required for those running 8.2.X. However, if you are upgrading from a version earlier than 8.2.14, see Section E.194 .

E.188.2. Changes

• Avoid failures when EXPLAIN tries to display a simple-form CASE expression (Tom Lane)

  If the CASE 's test expression was a constant, the planner could simplify the CASE into a form that confused the expression-display code, resulting in "unexpected CASE WHEN clause" errors.

• Fix assignment to an array slice that is before the existing range of subscripts (Tom Lane)

  If there was a gap between the newly added subscripts and the first pre-existing subscript, the code miscalculated how many entries needed to be copied from the old array's null bitmap, potentially leading to data corruption or crash.

• Avoid unexpected conversion overflow in planner for very distant date values (Tom Lane)

  The date type supports a wider range of dates than can be represented by the timestamp types, but the planner assumed it could always convert a date to timestamp with impunity.

• Fix pg_restore 's text output for large objects (BLOBs) when standard_conforming_strings is on (Tom Lane)

  Although restoring directly to a database worked correctly, string escaping was incorrect if pg_restore was asked for SQL text output and standard_conforming_strings had been enabled in the source database.

• Fix erroneous parsing of tsquery values containing ... & !(subexpression) | ... (Tom Lane)

  Queries containing this combination of operators were not executed correctly. The same error existed in contrib/intarray 's query_int type and contrib/ltree 's ltxtquery type.

• Fix buffer overrun in contrib/intarray 's input function for the query_int type (Apple)

  This bug is a security risk since the function's return address could be overwritten. Thanks to Apple Inc's security team for reporting this issue and supplying the fix. (CVE-2010-4015)

• Fix bug in contrib/seg 's GiST picksplit algorithm (Alexander Korotkov)

  This could result in considerable inefficiency, though not actually incorrect answers, in a GiST index on a seg column. If you have such an index, consider REINDEX ing it after installing this update. (This is identical to the bug that was fixed in contrib/cube in the previous update.)