Re: 7.3.2: test select_having ... FAILED

From: "Ed L(dot)" <pggeneral(at)bluepolka(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: 7.3.2: test select_having ... FAILED
Date: 2003-02-10 19:31:54
Message-ID: 200302101231.54912.pggeneral@bluepolka.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)bluepolka(dot)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)
> ...

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-02-10 19:36:07 Re: Why must SELECT DISTINCT, ORDER BY expressions must appear in target list?
Previous Message Tom Lane 2003-02-10 19:21:09 Re: renaming table leaves constraint behind [7.3.2]