pgsql: Address portability issues in bfe16d1a5 test output.
Address portability issues in bfe16d1a5 test output.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/9f478b4f19d8e26300ae19e42c26343f5791e32a
Modified Files
--------------
src/test/regress/expected/tsrf.out | 37 +++++++++++++++----------------------
src/test/regress/sql/tsrf.sql | 8 ++++----
2 files changed, 19 insertions(+), 26 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Hm, lapwing says this can't run in parallel with "misc" either :-(
I'm not sure about the change you made to have generate_series output
just one row --- isn't that losing some of the point of the test?
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On 2016-09-12 21:25:05 -0400, Tom Lane wrote:
Hm, lapwing says this can't run in parallel with "misc" either :-(
Gah. That's probably why I had originally had it running in the rules
group. But isn't that user_relns() test just a bad idea independent of
this failure? I mean what's the benefit of returning all relations
there, besides causing regression test churn? If you look at a git
blame you can see that there's quite a bit of changes in those few lines
of expected output.
I'm not sure about the change you made to have generate_series output
just one row --- isn't that losing some of the point of the test?
For me the test was mostly verifying that the pushdown logic does
something sensible, namely that the aggrefs are at the right level.
Andres
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Andres Freund <andres@anarazel.de> writes:
On 2016-09-12 21:25:05 -0400, Tom Lane wrote:
Hm, lapwing says this can't run in parallel with "misc" either :-(
Gah. That's probably why I had originally had it running in the rules
group. But isn't that user_relns() test just a bad idea independent of
this failure? I mean what's the benefit of returning all relations
there, besides causing regression test churn?
It looks like making your tables temp would work around it ...
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On 2016-09-12 21:33:03 -0400, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:
On 2016-09-12 21:25:05 -0400, Tom Lane wrote:
Hm, lapwing says this can't run in parallel with "misc" either :-(
Gah. That's probably why I had originally had it running in the rules
group. But isn't that user_relns() test just a bad idea independent of
this failure? I mean what's the benefit of returning all relations
there, besides causing regression test churn?It looks like making your tables temp would work around it ...
Right. But the more general question about the value of that test
remain. Not that the tables in this test matter given how simple they
are, but in general it doesn't hurt to have objects survive the
regression tests, to increase dump coverage.
Shouldn't we just drop that test?
Andres
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Andres Freund <andres@anarazel.de> writes:
On 2016-09-12 21:33:03 -0400, Tom Lane wrote:
It looks like making your tables temp would work around it ...
Right. But the more general question about the value of that test
remain. Not that the tables in this test matter given how simple they
are, but in general it doesn't hurt to have objects survive the
regression tests, to increase dump coverage.
Shouldn't we just drop that test?
Fair question --- it's not immediately obvious what that tests
that isn't covered at least as well by the adjacent tests.
The git history isn't much help: all of that came in in one big
commit from Tom Lockhart.
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On 2016-09-12 21:49:47 -0400, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:
On 2016-09-12 21:33:03 -0400, Tom Lane wrote:
It looks like making your tables temp would work around it ...
Right. But the more general question about the value of that test
remain. Not that the tables in this test matter given how simple they
are, but in general it doesn't hurt to have objects survive the
regression tests, to increase dump coverage.Shouldn't we just drop that test?
Fair question --- it's not immediately obvious what that tests
that isn't covered at least as well by the adjacent tests.
The git history isn't much help: all of that came in in one big
commit from Tom Lockhart.
Well, then let's drop it (including the definition of user_relns). Doing
so unless somebody protests pdq.
Andres
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers