| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David <dbree(at)duo-county(dot)com> |
| Cc: | pgsql-novice(at)postgresql(dot)org |
| Subject: | Re: Getting running totals |
| Date: | 2005-04-08 21:00:26 |
| Message-ID: | 16932.1112994026@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-novice |
David <dbree(at)duo-county(dot)com> writes:
> On Fri, Apr 08, 2005 at 01:33:53AM -0400, Tom Lane wrote:
>> SELECT to_char(date_trunc('month', t_date), 'Mon') AS "Month",
>> sum(transact.t_cost) AS "Month Ttl"
>> FROM transact
>> GROUP BY date_trunc('month', t_date)
>> ORDER BY date_trunc('month', t_date);
> That does it in a single command. I'm not sure I understand the full
> implications of what's occurring. It seems to me that ORDER BY can be
> sort of picky about what it will accept.
No pickier than the SELECT output list --- the rules are the same, in
fact. The reason that this is OK
SELECT to_char(date_trunc('month', t_date), 'Mon') AS "Month",
^^^^^^^^^^^^^^^^^^^^^^^^^^^
is that the parser sees that the part I underlined matches the GROUP BY
expression, and so it knows that the entire expression is well defined:
it will only have one value for each grouping value. The results of a
grouped query have to either have that property, or be aggregate
functions (which arrive at a single value per group too, of course).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David | 2005-04-08 21:09:13 | Re: Getting running totals |
| Previous Message | David | 2005-04-08 20:51:29 | Re: Getting running totals |