Re: GROUPING - Mailing list pgsql-hackers

From Andres Freund
Subject Re: GROUPING
Date
Msg-id 20150521154752.GZ27868@alap3.anarazel.de
Whole thread Raw
In response to Re: GROUPING  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: GROUPING  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
On 2015-05-21 16:19:27 +0100, Andrew Gierth wrote:
> 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?

I'd vote for either 0) do nothing or 1). I think the use case for
specifying 64+ (or even 32+) columns in grouping is pretty darn
slim. And as you said, it's not that hard to work around it if you need
it, and that's only going to be in an automated fashion anyway.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Minor improvements to alter_foreign_table.sgml
Next
From: Simon Riggs
Date:
Subject: Re: Redesigning checkpoint_segments