Bruce Momjian <[EMAIL PROTECTED]> writes:
> What is in the 7.2.X CVS that we would want to release?

CVS logs show the following as post-7.2.1 changes in REL7_2_STABLE branch.
Draw your own conclusions ...

                        regards, tom lane


2002-06-15 14:38  tgl

        * src/backend/utils/adt/ruleutils.c (REL7_2_STABLE): Back-patch 7.3
        fix to fully parenthesize UNION/EXCEPT/INTERSECT queries in
        ruleutils output.  The previous partial parenthesization was a hack
        to get around grammar restrictions that have since been fixed; and
        as Sam O'Connor pointed out, there were cases where it didn't work.

2002-06-07 17:53  momjian

        * contrib/intarray/: _int.c, _int.sql.in (REL7_2_STABLE): Please
        apply attached patch to contrib/intarray (7.2, 7.3).
        
             Fixed bug with '=' operator for gist__int_ops and
             define '=' operator for gist__intbig_ops opclass.
             Now '=' operator is consistent with standard 'array' type.
        
             Thanks Achilleus Mantzios for bug report and suggestion.
        
        Oleg Bartunov

2002-05-28 11:40  tgl

        * src/bin/pg_dump/pg_dump.c (REL7_2_STABLE): Repair incorrect
        dumping of user-defined aggregate with null initcond.  (Already
        fixed in current, but need a patch for 7.2.2.)

2002-05-28 11:25  tgl

        * contrib/rtree_gist/rtree_gist.c (REL7_2_STABLE): Fix a bug with
        building rtree_gist indexes.  Patch from Teodor Sigaev.

2002-05-28 11:22  tgl

        * src/backend/access/gist/gist.c (REL7_2_STABLE): Repair error with
        not adjusting active scans properly after gistSplit.  Patch from
        Teodor Sigaev.

2002-05-22 13:29  tgl

        * src/backend/utils/cache/relcache.c (REL7_2_STABLE): Make
        RelationForgetRelation error out if the relcache entry has nonzero
        reference count.  This avoids leaving dangling pointers around, as
        in recent bug report against sequences (bug# 671).

2002-05-21 14:50  tgl

        * src/pl/plpgsql/src/gram.y (REL7_2_STABLE): Repair OPEN
        cursor(args), which I broke on 11/29/01 with a change to be smarter
        about parentheses in read_sql_construct().  Sigh.

2002-05-14 14:16  tgl

        * src/backend/utils/adt/geo_ops.c (REL7_2_STABLE): Remove
        unnecessary pfree's in geometric operators.  At least one of these
        is actively dangerous, per bug report from Ewald Geschwinde
        14-May-02, and several of the rest look suspicious to me.  Since
        there is no longer any significant value in retail pfree's in these
        functions, just get rid of all of them for safety's sake.

2002-05-13 22:08  ishii

        * src/bin/: pg_dump/pg_dump.c, psql/startup.c (REL7_2_STABLE): Fix
        bug in pg_dump and psql (to reproduce the bug, just try pg_dump
        --nonexistingoption).
        
        per report from [EMAIL PROTECTED] on Thu, 09 May 2002 11:57:51 +0900
        (JST) at pgsql-patches list.
        
        Illegal long options to pg_dump makes core on some systems, since
        it lacks the last null sentinel of struct option array.
        
        Attached is a patch made by Mr. Ishida Akio <[EMAIL PROTECTED]>.

2002-05-05 13:38  tgl

        * src/pl/plpgsql/src/pl_funcs.c (REL7_2_STABLE):
        plpgsql_dstring_append was broken for long strings.

2002-04-30 21:27  inoue

        * src/backend/access/heap/heapam.c (REL7_2_STABLE): Change
        heap_get_latest_tid() so that a transaction can see changes made by
        the transaction itself.

2002-04-08 02:21  ishii

        * src/interfaces/libpq/fe-exec.c (REL7_2_STABLE): A backport patch.
         Fix PQescapeBytea/PQunescapeBytea so that they handle bytes >
        0x7f.  This is necessary for mulibyte character sequences.  See
        "[HACKERS] PQescapeBytea is not multibyte aware" thread posted
        around 2002/04/05 for more details.

2002-04-02 00:12  tgl

        * src/backend/commands/vacuum.c (REL7_2_STABLE): Fix CLOG
        truncation code to not do the Wrong Thing when there are already
        wrapped-around databases.  The unvacuumed databases might be fine,
        or they might not, but things will definitely not be fine if we
        remove the wrong CLOG segments.  Per trouble report from Gary
        Wolfe, 1-Apr-2002.

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Reply via email to