From: Tom Lane <tgl@sss.pgh.pa.us>
To: Edmund Lian <no.spam@address.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: Denormalizing during select
Date: Sat, 01 Mar 2003 12:13:32 -0500
Message-ID: <12195.1046538812@sss.pgh.pa.us> (raw)
In-Reply-To: <eq8n5vcad8ut4hk3dba1g4q27c54gr6dbs@4ax.com>
References: <200302241433.49502.josh@agliodbs.com>
<fhpl5v86vkhq26gifm9g4cb1kh2o2b6d6r@4ax.com>
<eq8n5vcad8ut4hk3dba1g4q27c54gr6dbs@4ax.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, no.spam@address.com
Subject: Re: Denormalizing during select
In-Reply-To: <12195.1046538812@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox