Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Greg StarkDate: 2009-08-22 01:31:57
Subject: Re: Feedback about Drupal SQL debugging
Previous:From: Tom LaneDate: 2009-08-22 01:23:09
Subject: Re: Feedback about Drupal SQL debugging

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group