Re: GROUPING

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GROUPING
Date: 2015-05-21 15:42:39
Message-ID: 27612.1432222959@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> 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.

I'd go with (1) --- it's cheap and doesn't lose any capability. If you
do (2), you'd lose useful operations like &, unless you cast back to int
which pretty much defeats the purpose. And (3) is just weird and will
confuse people, especially since numeric and int don't have identical
sets of operations.

Or we could just leave things alone. But (1) seems like pretty cheap
insurance.

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

I see no reason to do that. We don't need to copy Oracle-isms; the
language is already complicated enough.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-05-21 15:45:22 Re: Minor improvements to alter_foreign_table.sgml
Previous Message Fujii Masao 2015-05-21 15:40:40 Re: Redesigning checkpoint_segments