From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Dan Langille <dan(at)langille(dot)org>, Chad Thompson <chad(at)weblinkservices(dot)com>, <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: 7.3 "group by" issue |
Date: | 2003-02-23 19:59:35 |
Message-ID: | 200302231159.35826.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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 = x
> GROUP BY c1; -- <== refers to r.c1
>
> Clearly in this case you cannot claim that in general a.c1 == 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 issue,
rather than a theory one. That is, a human can easily tell the differences
when differently qualified table names are exactly equivalent even if a
parser cannot.
But I can definitely see where trying to accomodate this would be doing a
*lot* of programming to support sloppy syntax in a rather limited number of
useful cases.
More on BUGS
--
Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2003-02-23 20:19:08 | Re: [SQL] 7.3 GROUP BY differs from 7.2 |
Previous Message | codeWarrior | 2003-02-23 19:26:17 | Re: inserting multiple rows with one statement |