From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Sergey Burladyan <eshkinkot(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5234: ALTER TABLE ... RENAME COLUMN change view definition incorrectly |
Date: | 2009-12-10 16:00:12 |
Message-ID: | 603c8f070912100800m31f072d2ra4de92ce4cd1ae72@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, Dec 10, 2009 at 10:48 AM, Andrew Gierth
<andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>>>>>> "Robert" == Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>
> > On Thu, Dec 10, 2009 at 1:46 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >>
> >> My reading of the spec is that USING (and therefore NATURAL) is
> >> defined to join identically named columns. Therefore, renaming
> >> one of the input columns as the OP did *should* indeed *must*
> >> break the view. The problem is not how to make it work, it's how
> >> to give an error message that doesn't look like an internal
> >> failure.
>
> Robert> That seems ugly and unnecessary. I think we might be able to
> Robert> define ourselves out of this problem. We don't guarantee
> Robert> (and have never guaranteed) that selecting from a stored view
> Robert> will produce the same results as re-executing the original
> Robert> query. For example, * refers the list of columns at
> Robert> definition-time, not execution-time, and if a column is
> Robert> renamed, the view still refers to the same column; it doesn't
> Robert> start crashing, nor would we want it to. Similarly, here,
> Robert> the USING is internally converted to an equality join on the
> Robert> two columns, and the ambiguous output column is, I think,
> Robert> resolved in favor of one of them. I think we can just say
> Robert> that that conversion happens in toto at parse-time, just as
> Robert> the *-to-column-list conversion and the
> Robert> column-name-to-column-reference conversions do. This seems
> Robert> like a significantly more useful behavior and as a fringe
> Robert> benefit it simplifies the code.
>
> There's another possible solution (albeit a somewhat nontrivial one)
> which came up when a bunch of us were talking about this one on IRC;
> which is to handle the problem in the view deparse: if a column used
> in a USING clause has been renamed, add an alias to the query that
> renames it back, e.g.
> select ... from table1 as table1(v,a) join ... using (v)
>
> This would have to affect all the other references to that same column
> in the query, so you'd need to do something like this: before deparsing,
> walk the query looking for offending USING clauses, and make a list of
> renamings to apply to column names.
>
> I haven't tried actually implementing this, but I believe it is
> possible.
What advantage does this offer?
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-12-10 16:54:47 | Re: BUG #5234: ALTER TABLE ... RENAME COLUMN change view definition incorrectly |
Previous Message | Andrew Gierth | 2009-12-10 15:48:04 | Re: BUG #5234: ALTER TABLE ... RENAME COLUMN change view definition incorrectly |