I don't think so. It makes bugs like this hidden,but people will complaint pg is not that reliable because different stat data can make pg produce different result for the same query.
mybe we should make the regress test run under all the combination of query configures (enabale_*) to make sure all the query plan path is correct?
Em Sex, 2013-04-12 às 10:58 -0400, Tom Lane escreveu:
> Robert Haas <robertmhaas@gmail.com> writes: > > On Thu, Apr 11, 2013 at 1:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> The plan I'm considering is to get this written and committed to HEAD > >> in the next week, so that it can go out in 9.3beta1. After the patch > >> has survived a reasonable amount of beta testing, I'd be more comfortable > >> about back-patching into 9.2. > > > I'm not very sanguine about the chances that back-patching this won't > > provoke any screams of agony ... but I don't have a better idea, > > either. Letting queries return wrong answers isn't a superior > > solution, for sure. > > The only alternative I can see is to make a back-patch that just teaches > get_eclass_for_sort_expr() to compute valid nullable_relids for the sort > expression.
In my tests, after ANALYZE _bug_header and _bug_line, the query plan changes and query results returns as expected. Is this a chance that things isn't too bad?