Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master
Date
Msg-id 1707141.1760717920@sss.pgh.pa.us
Whole thread Raw
In response to Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master
List pgsql-hackers
Richard Guo <guofenglinux@gmail.com> writes:
> Having heard nothing but crickets and not wanting to leave this until
> the 11th hour before November, I'll plan to push the v1 patch next
> week, unless there are any objections.

I started to look at this again, and now I'm thinking that there is
indeed an issue related to "Query 1".  Recall that the test setup is

    CREATE TABLE t(id int);
    INSERT INTO t SELECT generate_series(1, 3);

If we do

regression=# SELECT id, 'XXX' FROM t GROUP BY ROLLUP (id, 1);

we get this, which seems correct:

 id | ?column? 
----+----------
    | XXX
  3 | XXX
  2 | XXX
  1 | XXX
  3 | XXX
  2 | XXX
  1 | XXX
(7 rows)

But leave out the "id" output, and look what happens:

regression=# SELECT 'XXX' FROM t GROUP BY ROLLUP (id, 1);
 ?column? 
----------
 
 XXX
 XXX
 XXX
 
 
 
(7 rows)

How can that be correct??  Simplifying further to

regression=# SELECT 'XXX' FROM t GROUP BY ROLLUP (id);
 ?column? 
----------
 XXX
 XXX
 XXX
 XXX
(4 rows)

restores sanity.  I've not dug into the code, but these two examples
make it look like we think that 'XXX' is dependent on '1', which
surely it is not, most especially since it shouldn't vary depending
on whether "id" is included as an output column.

This behavior is the same as in v17, but that doesn't make it not
broken.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: make tsearch use the database default locale
Next
From: Daniele Varrazzo
Date:
Subject: Re: Getting the SQLSTATE after a failed connection