| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
| Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: GROUPING |
| Date: | 2015-05-21 15:47:52 |
| Message-ID: | 20150521154752.GZ27868@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2015-05-21 16:02:02 | Re: Redesigning checkpoint_segments |
| Previous Message | Robert Haas | 2015-05-21 15:45:22 | Re: Minor improvements to alter_foreign_table.sgml |