> 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.
I understand the SQL, and this isn't a "sql" question else it would be on a different list, it is a PostgreSQL internals question and IMHO potential bug. The original query: select ycis_id, min(tindex), avg(tindex) from y where ycis_id = 15; Should NOT require a "group by" to get ycis_id in the results. ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq