From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | Daniele Orlandi <daniele(at)orlandi(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Attribute must be GROUPed.... ? |
Date: | 2003-05-01 00:31:58 |
Message-ID: | 25379.1051749118@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> Yeah, that can get to be a problem... In any case, you'll probably get
> other comments. Oh yeah, and you'll probably be asked for documentation
> comments if it's even considered since you're adding a visible GUC entry.
> :)
Well, it won't be --- diking out required error checks without providing
a substitute isn't my idea of a useful patch ;)
The SQL99 spec defines an improved version of this behavior which I
think is what Daniele really would like to have. Basically it says that
if column A can be proved functionally dependent on column B then you
only need to GROUP BY column B, and then you can use column A without
having to explicitly mention it in the GROUP BY list. "Functionally
dependent" means there is no possibility of A values being different in
rows with the same B value. The spec has a whole lot of verbiage about
possible ways to deduce functional dependency, but one easy one is where
column B is a primary key and column A is in its table.
If someone wants to implement the SQL99 behavior (or even just a useful
subset of it), that would be cool with me. It looks like a lot of work
though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Figueiredo Jr. | 2003-05-01 00:40:37 | Re: Cygwin PostgreSQL CVS build issues |
Previous Message | Andrew Dunstan | 2003-05-01 00:31:27 | Re: Attribute must be GROUPed.... ? |