To: Edmund Lian <no.spam@address.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: Denormalizing during select 
In-reply-to: <eq8n5vcad8ut4hk3dba1g4q27c54gr6dbs@4ax.com> 
References: <200302241433.49502.josh@agliodbs.com>
	<fhpl5v86vkhq26gifm9g4cb1kh2o2b6d6r@4ax.com>
	<eq8n5vcad8ut4hk3dba1g4q27c54gr6dbs@4ax.com>
Comments: In-reply-to Edmund Lian <no.spam@address.com>
	message dated "Tue, 25 Feb 2003 18:48:19 +0000"
Date: Sat, 01 Mar 2003 12:13:32 -0500
Message-ID: <12195.1046538812@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Edmund Lian <no.spam@address.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