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>
Subject: Re: 7.3 "group by" issue
Date: Sun, 23 Feb 2003 11:59:35 -0800
User-Agent: KMail/1.4.3
Cc: Dan Langille <dan@langille.org>,
	Chad Thompson <chad@weblinkservices.com>, <pgsql-sql@postgresql.org>
References: <Pine.LNX.4.44.0302230245070.2308-100000@peter.localdomain>
In-Reply-To: <Pine.LNX.4.44.0302230245070.2308-100000@peter.localdomain>
MIME-Version: 1.0
Message-Id: <200302231159.35826.josh@agliodbs.com>
Content-Transfer-Encoding: quoted-printable

Peter,

> Consider JOIN to be a black-box function, then you'd be writing something
> like
>
> SELECT a.c1, count(a.c2)
> FROM func(a, b) AS r (c1, c2, c3, c4, c5)
> WHERE b.c5 =3D x
> GROUP BY c1; -- <=3D=3D refers to r.c1
>
> Clearly in this case you cannot claim that in general a.c1 =3D=3D r.c1.
>
> If the func() is an inner join, then the claim is true, but if it's an
> outer join it's not.  The scoping rules for inner and outer joins are the
> same, and that might be considered a good thing.

I see what you mean ... though I still hold that it's an implementation iss=
ue,=20
rather than a theory one.   That is, a human can easily tell the difference=
s=20
when differently qualified table names are exactly equivalent even if a=20
parser cannot.=20=20

But I can definitely see where trying to accomodate this would be doing a=
=20
*lot* of programming to support sloppy syntax in a rather limited number of=
=20
useful cases.

More on BUGS

--=20
Josh Berkus
Aglio Database Solutions
San Francisco