From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Functional dependencies and GROUP BY - for subqueries |
Date: | 2013-04-26 14:24:50 |
Message-ID: | 10862.1366986290@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> writes:
> The reason being, it doesn't look into the subqueries (in FROM clause) to
> infer that p.product_id is essentially product.product_id which is a
> primary key.
Right.
> Attached find a crude patch to infer the same by traversing subqueries.
I think this is probably a bad idea. We could spend an infinite amount
of code this way, with ever-increasing runtime cost and ever-decreasing
usefulness, and where would we stop? I'm also a bit concerned about
allowing illegal queries due to bugs of omission in the
ever-more-complex checking code, which could be quite hard to find, and
when we did find them we'd be faced with a backwards compatibility break
if we fix them.
A larger point is that the patch as proposed doesn't fix the stated
problem, because it only descends into written-out subqueries. It
would only succeed at looking into views if we applied it after
rewriting, rather than in the parser. That's really not going to work.
It would be a complete disaster if the dependencies of a query that
references a view depend on the view's contents.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-04-26 14:29:41 | Re: libpq COPY handling |
Previous Message | Simon Riggs | 2013-04-26 14:09:27 | Re: Substituting Checksum Algorithm (was: Enabling Checksums) |