Re: Implementation of GROUPING SETS (T431: Extended grouping capabilities)

2009/5/13 Joshua Tolley <eggyknap@gmail.com>:
> On Wed, May 13, 2009 at 06:29:41AM +0200, Pavel Stehule wrote:
>> 2009/5/13 Joshua Tolley <eggyknap@gmail.com>:
>> > On Tue, May 12, 2009 at 11:20:14PM +0200, Pavel Stehule wrote:
>> >> this patch has some bugs but it is good prototype (it's more stable
>> >> than old patch):
>> >
>> > I'm not sure if you're at the point that you're interested in bug reports, but
>> > here's something that didn't behave as expected:
>> >
>> > 5432 josh@josh*# create table gsettest (prod_id integer, cust_id integer,
>> > quantity integer);
>> > CREATE TABLE
>> > 5432 josh@josh*# insert into gsettest select floor(random() * 10)::int,
>> > floor(random() * 20)::int, floor(random() * 10)::int from generate_series(1,
>> > 100);
>> > INSERT 0 100
>> > 5432 josh@josh*# select prod_id, cust_id, sum(quantity) from gsettest group by
>> > cube (prod_id, cust_id) order by 1, 2;
>> >  prod_id | cust_id | sum
>> > ---------+---------+-----
>> >       5 |       7 |   4
>> >       8 |      16 |   3
>> >       9 |      19 |   8
>> >       4 |      13 |   3
>> >       8 |       8 |  15
>> >       5 |       2 |   4
>> >       7 |       6 |   7
>> >       6 |       6 |   3
>> > </snip>
>> >
>> > Note that the results aren't sorted. The following, though, works around it:
>>
>> I thing, so result should not be sorted - it's same like normal group by.
>
> Normal GROUP BY wouldn't have ignored the ORDER BY clause I included.
>

sorry, now I understand - simply it is a bug. I fixed it

Thank You
Pavel

> - Josh
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkoKxLQACgkQRiRfCGf1UMOj/wCgkPnRiheRr+BNPLBCjzA9XlFW
> 0rsAoI0eOGSGlxIv0eNB8zqum7kw/Cqw
> =FCTz
> -----END PGP SIGNATURE-----
>
>