* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > Right. It strikes me as a relativly small amount of work to get the
> > initial "just add the columns to the group by" logic implemented.
> Well, no, you *aren't* adding the columns to the GROUP BY. You're just
> not throwing the error. You really don't want to add redundant columns
> to GROUP BY because it makes more work for the planner and executor
> (unless the planner can figure out they're redundant, which in itself
> takes work).
Hmm, right. Possibly also add some bit of info to pass to something
down the line, if necessary.
> This is a bit trickier than it looks because it makes the validity of a
> query dependent on the existence of an appropriate uniqueness
> constraint; thus for example DROP CONSTRAINT might invalidate a stored
> rule or view. See prior discussions.
Ah, yes. Couldn't the dependency system be used to handle this though?
If you try to drop that constraint it'll complain unless you use cascade
which would drop the view? I'll try and find older discussions. Sadly,
I don't see it on the TODO. Perhaps I can add it.
In response to
pgsql-hackers by date
|Next:||From: Greg Stark||Date: 2009-08-22 01:31:57|
|Subject: Re: Feedback about Drupal SQL debugging|
|Previous:||From: Tom Lane||Date: 2009-08-22 01:23:09|
|Subject: Re: Feedback about Drupal SQL debugging |