Thread: 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(-)

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

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

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

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

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

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