On Tue, Jun 8, 2010 at 3:21 PM, Tom Lane <t...@sss.pgh.pa.us> 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 <where clause> ... If AP is an equality AND-component of the <search condition> simply contained in the <where clause> and one comparand of AP is a column reference CR, and the other comparand of AP is a <literal>, 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers