Re: GROUPING - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: GROUPING
Date
Msg-id 87h9r6ynms.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: GROUPING  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: GROUPING  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: GROUPING  (Andres Freund <andres@anarazel.de>)
Re: GROUPING  (David Fetter <david@fetter.org>)
List pgsql-hackers
>>>>> "Dean" == Dean Rasheed <dean.a.rasheed@gmail.com> writes:
>> Consider that in both MSSQL 2014 and Oracle 12 the limit on the number>> of arguments in a GROUPING() expression is
...1.
 
Dean> Actually Oracle haven't quite followed the standard. They have 2Dean> separate functions: GROUPING() which only
allows1 parameter, andDean> GROUPING_ID() which allows multiple parameters, and returns aDean> bitmask like our
GROUPING()function. However, theirDean> GROUPING_ID() function seems to return an arbitrary precisionDean> number and
allowsan arbitrary number of parameters (well, IDean> tested it up 70 to prove it wasn't a 64-bit number).
 

True. It can handle more than 128 bits, even - I gave up trying after that.

So. Options:

1) change GROUPING() to return bigint and otherwise leave it as is.

2) change GROUPING() to return numeric.

3) change GROUPING() so that the result type varies with the number of
args. I don't see anything in the spec that actually forbids this - it
just says the return type is implementation-defined exact numeric.

A) in addition to any of the above, implement GROUPING_ID() as a simple
alias for GROUPING().

4) leave GROUPING() alone and add a separate GROUPING_ID() with a
different return type.

B) We don't currently have GROUP_ID() - does anyone want it?

*) any other ideas?

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: CTE optimization fence on the todo list?
Next
From: Fujii Masao
Date:
Subject: Re: Redesigning checkpoint_segments