Content-Type: text/plain;
  charset="iso-8859-1"
From: Josh Berkus <josh@agliodbs.com>
Organization: Aglio Database Solutions
To: Peter Eisentraut <peter_e@gmx.net>,
	Dan Langille <dan@langille.org>
Subject: Re: 7.3 "group by" issue
Date: Sat, 22 Feb 2003 11:34:45 -0800
User-Agent: KMail/1.4.3
Cc: Chad Thompson <chad@weblinkservices.com>,
	<pgsql-sql@postgresql.org>
References: <Pine.LNX.4.44.0302220245460.2067-100000@peter.localdomain>
In-Reply-To: <Pine.LNX.4.44.0302220245460.2067-100000@peter.localdomain>
MIME-Version: 1.0
Message-Id: <200302221134.45226.josh@agliodbs.com>
Content-Transfer-Encoding: quoted-printable

Peter,

> This does not work because the first select list item references a column
> inside a join, which is not (necessarily) mathematically identical to the
> column that arrives outside of the join and is in the GROUP BY clause.
> (Think of an outer join: the column outside the join might contain added
> null values.  Of course you are using an inner join, but the constructs
> work the same either way.)

Hmmm ... I don't see that.   I can see that it might be practically=20
difficult-to-impossible to make the planner distinguish between cases where=
=20
the columns in the select list are different from the columns in the JOIN=
=20
series and when they aren't, but as a theory issue I just don't buy it.

What Dan's doing is:

SELECT a.c1, count(a.c2)
FROM a JOIN b
WHERE b.c5 =3D x
GROUP BY c1

In a case like this, a.c1 =3D=3D c1 without possibility of ambiguity.  The =
only=20
difference is whether or not a table qualifier is used on the name, which i=
n=20
theory should *only* make a difference when there are more than one table i=
n=20
the query with that column name.=20=20=20

So if you're saying that that kind of equivalency is a challenging parser=
=20
implementation issue, then I'm with you.   If you're saying its a SQL theor=
y=20
issue, though, I don't agree at all.

--=20
Josh Berkus
Aglio Database Solutions
San Francisco