Re: 7.3.2: test select_having ... FAILED - Mailing list pgsql-general

From Ed L.
Subject Re: 7.3.2: test select_having ... FAILED
Date
Msg-id 200302101231.54912.pggeneral@bluepolka.net
Whole thread Raw
In response to Re: 7.3.1: test select_having ... FAILED  ("Ed L." <pggeneral@bluepolka.net>)
Responses Re: 7.3.2: test select_having ... FAILED
List pgsql-general
The select_having regression test fails pg 7.3.2 just as it did in
7.3.1.  Upon inspection, the 7.3.2 code (select_having.sql) does not
include the "ORDER BY" clauses needed to pass the test.  The CVS log
indicates you fixed the problem in rev 1.8 (the head) of
select_having.sql on 2003-11-21, but CVS shows the following tags:

    REL7_3_2: 1.7
        REL7_2_4: 1.4
        REL7_3_STABLE: 1.7.0.2

This is not a functional problem, just a red herring.  I don't
understand why this committed fix is not making its way into the
latest releases?

Thanks,
Ed


On Saturday December 28 2002 10:13, Ed L. wrote:
> On Saturday 28 December 2002 14:26, Tom Lane wrote:
> > "Ed L." <pggeneral@bluepolka.net> writes:
> > > Looks like this select_having regression test was fixed by tgl
> > > on the HEAD Nov 21 2002 to use ORDER BY queries to avoid random
> > > outputs, but I was surprised it did not make it into 7.3.1.
> >
> > The change I made was unrelated to 7.3.*.  I suspect you are
> > looking at a locale issue --- was this a "make check" or "make
> > installcheck", and if the latter, what locale is the server
> > using?
>
> This was encountered with the following:
>
>     cd .../src/test/regress
>     gmake clean
>     gmake all runtest
>
> As for locales, don't know much about those.  This is a fresh
> redhat 8.0 install with plain vanilla defaults for US english, etc.
>  env | grep LC shows nothing. LANG=en_US.UTF-8, the default
> setting.  Still, my relatively uninformed look into the regression
> test files shows me missing ORDER BY clauses, as you can see below,
> which would seem to explain it.
>
> Ed
>
> # pwd
> .../postgresql-7.3.1/src/test/regress
> # diff expected/select_having.out results/select_having.out
> 29d28
> <  3 | BBBB
> 30a30
>
> >  3 | BBBB
>
> 46d45
> <  XXXX     |   0
> 47a47
>
> >  XXXX     |   0
>
> # cat -n expected/select_having.out
>     ...
>     24  -- HAVING is equivalent to WHERE in this case
>     25  SELECT b, c FROM test_having
>     26          GROUP BY b, c HAVING b = 3;
>     27   b |    c
>     28  ---+----------
>     29   3 | BBBB
>     30   3 | bbbb
>     31  (2 rows)
>     ...
> # cat -n results/select_having.out
>     ...
>     24  -- HAVING is equivalent to WHERE in this case
>     25  SELECT b, c FROM test_having
>     26          GROUP BY b, c HAVING b = 3;
>     27   b |    c
>     28  ---+----------
>     29   3 | bbbb
>     30   3 | BBBB
>     31  (2 rows)
>     ...


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: renaming table leaves constraint behind [7.3.2]
Next
From: Tom Lane
Date:
Subject: Re: Why must SELECT DISTINCT, ORDER BY expressions must appear in target list?