On Thu, Dec 10, 2009 at 12:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Dec 10, 2009 at 11:54 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> The problem with USING is that it is not merely a join condition but >>> affects the set of columns emitted by the join. It can't be converted >>> to a simple ON without changing the semantics, and I don't believe we >>> should try. > >> The OP seemed to be pretty clear on what the semantics should be, and >> I'm not confused either. Why are you? :-) > > I'm not confused: it's an error condition. You have not explained why > it isn't.
Well, it's obviously not an error condition at present, because the view works perfectly well. As far as running SELECT statements against the view, the QUERY structure in ev_rewrite is semantically equivalent to one without the usingClause. buildMergedJoinVar() builds a target list entry that refers to one or both of the underlying base tables, using COALESCE if necessary. Nothing in that join var depends IN ANY WAY on the usingClause. The JoinExpr similarly gets rewritten in terms of an equality construct - while it's true that the usingClause is still present, nothing outside the parser/deparser actually looks at it. For that reason, your claim that we CAN'T rewrite USING to a simple ON without changing the semantics seems to me to be false. For purposes of 99.44% of the code, we are already doing it. The only problem is, after we do it, and after using that rewritten version to execute the query, we maintain the fiction that we haven't done it when we dump the view back out, leading to inconsistent results. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
