Re: Functional dependencies and GROUP BY

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Functional dependencies and GROUP BY
Date: 2010-06-08 00:59:41
Message-ID: AANLkTinP1Xa99mjT-KZuUAbyO40LJpWLtvUchGDrKf51@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/6/8 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> I have developed a patch that partially implements the "functional
> dependency" feature that allows some columns to be omitted from the
> GROUP BY clause if it can be shown that the columns are functionally
> dependent on the columns in the group by clause and therefore guaranteed
> to be unique per group.  The full functional dependency deduction rules
> are pretty big and arcane, so I concentrated on getting a useful subset
> working.  In particular:

> Also, when a column is compared with a constant, it can appear
> ungrouped:
>
> SELECT x, y FROM tab2 WHERE y = 5 GROUP BY x;

I don't see why it should be allowed. I see the insist that y must be
unique value so it is ok to be ungrouped but the point of discussion
is far from that; Semantically y is not grouping key.

In addition, what if y is implicitly a constant? For example,

SELECT x, y FROM tab2 WHERE y = a AND a = 5 GROUP BY x;

or there should be more complicated example including JOIN cases. I
don't believe we can detect all of such cases. If the simple case is
allowed, users don't understand why the complicated case doesn't allow
sometimes. So it'll not be consistent.

Finally, it may hide unintended bugs. ORM tools may make WHERE clause
in some conditions and don't in other conditions.

Regards,

--
Hitoshi Harada

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-06-08 01:02:28 Re: How to get permission to debug postgres?
Previous Message Tom Lane 2010-06-08 00:46:38 Re: [PATCH] Fix leaky VIEWs for RLS