* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Hm. The problem with that is that one of the benefits we'd like to get
> from this is an efficiency win: the generated plan ought to only group
> by the PK, not uselessly sort/group by everything in the row. I suppose
> we could have the planner reverse-engineer its way to that, but it seems
> awfully slow and clunky to add on the extra columns and then reason our
> way to removing them again.
That's certainly a good point. Another issue that I realized when
thinking about this again- if someone wanted to *drop* a column that's
part of a PK (since it turned out to not be necessary, for example), and
then wanted to recreate the rule based on what was stored in the
catalog, they wouldn't be able to without modifying it, and that's
certainly be annoying too.
Guess my 2c would be for creating the dependency. I really dislike the
idea of the rule just all of a sudden breaking.
Thanks,
Stephen