Hi, Mark,
Mark Woodward wrote:
>> Stephen Frost wrote:
>>
>>> select ycis_id, min(tindex), avg(tindex) from y where ycis_id = 15;
>> But back to the query the issue comes in that the ycis_id value is
>> included with the return values requested (a single row value with
>> aggregate values that isn't grouped) - if ycis_id is not unique you will
>> get x number of returned tuples with ycis_id=15 and the same min() and
>> avg() values for each row.
>> Removing the ycis_id after the select will return the aggregate values
>> you want without the group by.
>
> I still assert that there will always only be one row to this query. This
> is an aggregate query, so all the rows with ycis_id = 15, will be
> aggregated. Since ycis_id is the identifying part of the query, it should
> not need to be grouped.
>
> My question, is it a syntactic technicality that PostgreSQL asks for a
> "group by," or a bug in the parser?
I think that it's a lack of special-casing the = operator. Imagine
"where ycis_id>15" or "where ycis_id @|< $RECTANGLE" or other (probably
user defined) operators on (probably user defined) datatypes.
The parser has no real knowledge what the operators do, it simply
requests one that returns a bool.
One could make the parser to special case the = operator, and maybe some
others, however I doubt it's worth the effort.
HTH,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org
