Re: BUG #5234: ALTER TABLE ... RENAME COLUMN change view definition incorrectly

On Thu, Dec 10, 2009 at 12:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Dec 10, 2009 at 11:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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