> 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.
