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
signature.asc
Description: OpenPGP digital signature
