Re: Denormalizing during select

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Edmund Lian <no(dot)spam(at)address(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Denormalizing during select
Date: 2003-03-01 17:13:32
Message-ID: 12195.1046538812@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Edmund Lian <no(dot)spam(at)address(dot)com> writes:
> Answering my own question: kind of. The problem with custom aggregates
> is that they need to be used with a "group by" clause, and this means
> that the select cannot return columns that are not aggregates of some
> kind. What I'm trying to return are rows that are a combination of
> columns and aggregates.

This strikes me as evidence of fuzzy thinking. What sets of rows are
the aggregates taken over? Which column values within those sets of
rows do you expect the non-aggregated column references to return?
If the columns aren't the ones grouped by, seems like you have an
inherently undefined result.

If you know for some reason that there will be only one unique value
of a column in a grouped row set, or you don't actually much care which
one you get, then you could use MIN() or MAX() on the column reference
to make it look like a kosher query.

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Greg Stark 2003-03-01 17:53:41 Re: Denormalizing during select
Previous Message Tom Lane 2003-03-01 17:07:14 Re: Epoch extraction