On Fri, Feb 10, 2012 at 10:52 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Feb 9, 2012 at 6:21 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Although this is a bug fix, it's a nontrivial change in the logic and >>> so I'm hesitant to back-patch into stable branches. Given the lack of >>> prior complaints, maybe it would be best to leave it unfixed in existing >>> branches? Not sure. Thoughts? > >> I guess I'd be in favor of back-patching it, if that doesn't look like >> too much of a job. We shouldn't assume that because only one person >> reports a problem, no one else has been or will be affected. > > I don't think it's too much work --- what I'm more worried about is > introducing new bugs. If I apply it only in HEAD then it will go > through a beta test cycle before anybody relies on it in production. > I *think* the patch is okay, but I've been wrong before.
Well, I'm not going to second-guess your judgement too much, but my general feeling is that it's worth taking a bit of risk to get pg_dump to DTRT. Dump and restore failures are extremely painful and difficult to work around, so in my book they rank pretty highly in the list of things that are important to get fixed. So if you're on the fence, I'd lean toward back-patching. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
