Re: Functional dependencies and GROUP BY

Поиск
Список
Период
Сортировка
Искать
От
Greg Stark
Тема
Re: Functional dependencies and GROUP BY
Дата
Msg-id
AANLkTilLkskDUZLgzYzb6B_CeS08h862mOveTDcxVLaO@mail.gmail.com
Ответ на
Список
Дерево обсуждения
Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Dean Rasheed <dean.a.rasheed@gmail.com>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Dean Rasheed <dean.a.rasheed@gmail.com>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Alex Hunsaker <badalex@gmail.com>
Re: Functional dependencies and GROUP BY Stephen Frost <sfrost@snowman.net>
Re: Functional dependencies and GROUP BY Rob Wultsch <wultsch@gmail.com>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Greg Stark <gsstark@mit.edu>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Stephen Frost <sfrost@snowman.net>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Stephen Frost <sfrost@snowman.net>
Re: Functional dependencies and GROUP BY Greg Stark <gsstark@mit.edu>
Re: Functional dependencies and GROUP BY Greg Stark <gsstark@mit.edu>
Re: Functional dependencies and GROUP BY Pavel Stehule <pavel.stehule@gmail.com>
Re: Functional dependencies and GROUP BY Hitoshi Harada <umi.tanuki@gmail.com>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Tom Lane <tgl@sss.pgh.pa.us>
Re: Functional dependencies and GROUP BY Peter Eisentraut <peter_e@gmx.net>
Re: Functional dependencies and GROUP BY Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>
Re: Functional dependencies and GROUP BY Greg Stark <gsstark@mit.edu>
Re: Functional dependencies and GROUP BY Stephen Frost <sfrost@snowman.net>
On Tue, Jun 8, 2010 at 3:21 PM, Tom Lane  wrote:

> The question is why bother to recognize *any* cases of this form.
> I find it really semantically ugly to have the parser effectively
> doing one deduction of this form when the main engine for that type
> of deduction is elsewhere; so unless there is a really good argument
> why we have to do this case (and NOT "it was pretty easy"), I don't
> want to do it.

Well it does appear to be there:

4.18.11 Known functional dependencies in the result of a 
...
If AP is an equality AND-component of the  simply
contained in the  and one comparand of AP is a column
reference CR, and the other comparand of AP is a , then let
CRC be the counterpart of CR in R. {}   {CRC} is a known functional
dependency in R, where {} denotes the empty set.

NOTE 43 — An SQL-implementation may also choose to recognize {}
{CRC} as a known functional dependency if the other comparand is a
deterministic expression containing no column references.
...


Since Peter's not eager to implement the whole section -- which does
seem pretty baroque -- it's up to us to draw the line where we stop
coding and declare it good enough. I think we're all agreed that
grouping by a pk is clearly the most important case. It may be
important to get some other cases just so that the PK property carries
through other clauses such as joins and group bys. But ultimately the
only thing stopping us from implementing the whole thing is our
threshold of pain for writing and maintaining the extra code.

-- 
greg

В списке pgsql-hackers по дате отправления
От: Stephen Frost
Дата:
От: Tom Lane
Дата:
FAQ