Skip site navigation (1) Skip section navigation (2)

Re: 8.4 open items list

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.4 open items list
Date: 2009-03-27 17:46:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

> On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas<robertmhaas(at)gmail(dot)com>  wrote:
>> I think we should also boot everything in the "pre-existing bugs"
>> category,

I don't agree.  I think we should fix as many of those as we can without 
holding up the release.  Having been (briefly) in charge of Another Open 
Source Database's bug list, I've seen where ignoring pre-existing bugs 
can lead, and it's not at all pretty.

These bugs strike me as especially pernicious and to need fixing before 
8.4 release (but NOT before Beta):

     * GiST picksplit (maybe GIN too?) can fail
     * Perl/libxml incompatibility
     * BUG #4721: bad side-effects of limiting number of clauses that 
predtest will consider
     * BUG #4694: uppercase path problem on Windows

This one is also really bad, but probably only Doc-patchable.  However, 
can SQL/XML really be said to be core functionality if it only works in 
     * BUG #4622: xpath only work in utf-8 server encoding

I'll also take a stab at this one, because it looks easy:
     * contrib/intarray opclass definition needs updating

And Magnus fixed this one:
     * Path separator consistency on Windows

The other "existing" bugs I think relate to extreme corner cases (e.g. 
ENUMs of DOMAINS) and/or may be feature requests rather than bugs (e.g. 
Cover Density Ranking) so I think can safely be put off until 8.4.1 or 

--Josh Berkus

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2009-03-27 17:48:58
Subject: Re: 8.4 open items list
Previous:From: Robert HaasDate: 2009-03-27 17:32:44
Subject: Re: Should SET ROLE inherit config params?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group