From: | Daniele Orlandi <daniele(at)orlandi(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Attribute must be GROUPed.... ? |
Date: | 2003-04-30 21:21:29 |
Message-ID: | 3EB03E59.8060102@orlandi.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I always had been doubious about the "must" in the error message
"Attribute must be GROUPed or used in an aggregate function".
I certainly agree that there are many situations in which having an
ungrouped attribute in the target list is nonsense (undefined), but I
sometimes find situations in which it would be perfetcly meaningful.
For example, suppose that you join two tables and the field you group by
appears to be the primary key of one of the tables. In this case if I
put any of the fields in that table in the target list, it will always
be well defined and would make certain queries much simpler.
In SQL:
# create table cities (id int primary key,name text);
# create table people (fullname text,city_id int references cities(id));
# select name,count(*) from people,cities where people.city_id=cities.id
group by city_id;
name | count
------------+-------------
New York | 10
Los Angeles | 15
Seveso | 1
....
Here follows a patch that makes this behaviour configurable via a
configuration variable. I apologize in advance if there's something
stupid, it's my first patch on postgresql...
The default is the current behaviour but I would propose to change the
default to be more permissive.
Bye!
--
Daniele Orlandi
Planet Srl
Attachment | Content-Type | Size |
---|---|---|
pgsql-group.diff | text/plain | 3.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua Drake | 2003-04-30 21:39:48 | Re: Upgrade to RedHat 9.0 broke PostgreSQL |
Previous Message | Tom Lane | 2003-04-30 19:14:00 | Planned changes in backend memory management |