Re: Feedback about Drupal SQL debugging - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Feedback about Drupal SQL debugging
Date
Msg-id 20090822013144.GY23840@tamriel.snowman.net
Whole thread Raw
In response to Re: Feedback about Drupal SQL debugging  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Feedback about Drupal SQL debugging  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.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.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Feedback about Drupal SQL debugging
Next
From: Greg Stark
Date:
Subject: Re: Feedback about Drupal SQL debugging