Re: Allow CREATE OR REPLACE VIEW to rename the columns - Mailing list pgsql-hackers

From btfujiitkp
Subject Re: Allow CREATE OR REPLACE VIEW to rename the columns
Date
Msg-id f9dcdef78c124517edc9e5e5880f651e@oss.nttdata.com
Whole thread Raw
In response to Re: Allow CREATE OR REPLACE VIEW to rename the columns  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Allow CREATE OR REPLACE VIEW to rename the columns
List pgsql-hackers
2019-10-31 21:01 に Fujii Masao さんは書きました:
> On Thu, Oct 31, 2019 at 7:59 PM Ibrar Ahmed <ibrar.ahmad@gmail.com> 
> wrote:
>> 
>> 
>> 
>> On Thu, Oct 31, 2019 at 12:32 PM Fujii Masao <masao.fujii@gmail.com> 
>> wrote:
>>> 
>>> On Thu, Oct 31, 2019 at 1:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> >
>>> > Fujii Masao <masao.fujii@gmail.com> writes:
>>> > > Currently CREATE OR REPLACE VIEW command fails if the column names
>>> > > are changed.
>>> >
>>> > That is, I believe, intentional.  It's an effective aid to catching
>>> > mistakes in view redefinitions, such as misaligning the new set of
>>> > columns relative to the old.  That's particularly important given
>>> > that we allow you to add columns during CREATE OR REPLACE VIEW.
>>> > Consider the oversimplified case where you start with
>>> >
>>> > CREATE VIEW v AS SELECT 1 AS x, 2 AS y;
>>> >
>>> > and you want to add a column z, and you get sloppy and write
>>> >
>>> > CREATE OR REPLACE VIEW v AS SELECT 1 AS x, 3 AS z, 2 AS y;
>>> >
>>> > If we did not throw an error on this, references that formerly
>>> > pointed to column y would now point to z (as that's still attnum 2),
>>> > which is highly unlikely to be what you wanted.
>>> 
>>> This example makes me wonder if the addtion of column by
>>> CREATE OR REPLACE VIEW also has the same (or even worse) issue.
>>> That is, it may increase the oppotunity for users' mistake.
>>> I'm thinking the case where users mistakenly added new column
>>> into the view when replacing the view definition. This mistake can
>>> happen because CREATE OR REPLACE VIEW allows new column to
>>> be added. But what's the worse is that, currently there is no way to
>>> drop the column from the view, except recreation of the view.
>>> Neither CREATE OR REPLACE VIEW nor ALTER TABLE support
>>> the drop of the column from the view. So, to fix the mistake,
>>> users would need to drop the view itself and recreate it. If there 
>>> are
>>> some objects depending the view, they also might need to be 
>>> recreated.
>>> This looks not good. Since the feature has been supported,
>>> it's too late to say that, though...
>>> 
>>> At least, the support for ALTER VIEW DROP COLUMN might be
>>> necessary to alleviate that situation.
>>> 
>> 
>> - Is this intentional not implemented the "RENAME COLUMN" statement 
>> for
>> VIEW because it is implemented for Materialized View?
> 
> Not sure that, but Tom's suggestion to support ALTER VIEW RENAME COLUMN
> sounds reasonable whether we support the rename of columns when 
> replacing
> the view definition, or not. Attached is the patch that adds support 
> for
> ALTER VIEW RENAME COLUMN command.
> 
>> I have made just a similar
>> change to view and it works.
> 
> Yeah, ISTM that we made the same patch at the same time. You changed 
> gram.y,
> but I added the following changes additionally.
> 
> - Update the doc
> - Add HINT message emit when CRAETE OR REPLACE VIEW fails to rename the 
> columns
> - Update tab-complete.c


I review your patch, and then I found that tab complete of "alter 
materialized view" is also not enough.
So, I made a small patch referencing your patch.

Regards,


Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: cost based vacuum (parallel)
Next
From: Michael Paquier
Date:
Subject: Re: Logical replication wal sender timestamp bug