From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org, neha khatri <nehakhatri5(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Subject: | Re: bytea_output vs make installcheck |
Date: | 2017-02-15 05:30:49 |
Message-ID: | 14187.1487136649@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> I don't quite see the point of this - there's a lot of settings that cause spurious test failures. I don't see any point fixing random cases of that. And I don't think the continual cost of doing so overall is worth the minimal gain.
> What's your reason to get this fixed?
FWIW, I'm inclined to do something about Jeff's nearby complaint about
operator_precedence_warning, because the cause of that failure is pretty
obscure. I'm less excited about this one, because it should be obvious
what happened to anyone who looks at the regression diffs.
In general I think there's value in "make installcheck" passing when
it reasonably can, but you're quite right that there's a lot of setting
changes that would break it, and not all are going to be practical to
fix.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2017-02-15 05:43:04 | Re: DROP SUBSCRIPTION and ROLLBACK |
Previous Message | Michael Paquier | 2017-02-15 05:30:13 | Re: CREATE TABLE with parallel workers, 10.0? |