Re: Feedback about Drupal SQL debugging

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Jean-Michel Pouré <jm(at)poure(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Feedback about Drupal SQL debugging
Date: 2009-08-22 01:31:44
Message-ID: 20090822013144.GY23840@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* 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.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-08-22 01:31:57 Re: Feedback about Drupal SQL debugging
Previous Message Tom Lane 2009-08-22 01:23:09 Re: Feedback about Drupal SQL debugging