| 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: | Whole Thread | Raw Message | 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.... ? |